Handle 'Request was throttled' more gracefully in sign

[tomquas]

Is this a feature request or a bug?

you choose

What is the current behavior?

we need to sign 20+ extension build variants for different brands and configurations.
during the build, more often than not we do see

response: {"detail":"Request was throttled. Expected available in 1 second."}

and we have to catch up on where things failed. total pain in the neck.

What is the expected or desired behavior?

just sign em...

Version information (for bug reports)

node --version && npm --version && web-ext --version
v10.16.0
6.9.0
3.1.0

[rpl]

That message is actually the response web-ext sign got from the server, and so this is not something we can investigate and/or change on the "web-ext" tool side.
It should be actually reported to the addons-server github issues: https://github.com/mozilla/addons-server/issues

In the meantime I'm closing this as invalid (from a "web-ext cli tool" perspective).

[kumar303]

@tomquas sorry for the inconvenience. The rate limits are in place to combat real and ongoing attacks against our systems. I suggest sleeping your script after signing each new version or adding a wait-retry-loop each time you see a throttled response code.

[Rob--W]

@diox This could be solved at the web-ext side by detecting the specific error type and then automatically retrying after waiting for the specified amount of time. Is it acceptable from AMO's side of view that we implement it here like that?

[diox]

Yes, but with some caveats. You can use the Retry-After header if present, and wait that amount of time plus one second to be on the safe side. That value is not a guarantee though, it's just a suggestion, the developer might still be rate limited after waiting the initial value returned. You should wait for mozilla/addons#6774 to be implemented which will make the value more accurate for developers submitting a lot of add-ons (especially those submitting more than 20 per hour)

If the Retry-After header is absent, I suggest you don't even retry. We may remove that header in some cases and in that case, it's pointless to keep submitting blindly.

[Rob--W]

Thanks diox. I've reopened this issue and marked it as a feature request. The throttling is not a bug (which is why this report was initially closed), but we can do something about it.

[rpl]

@Rob--W I'm sure that you may already noticed it, but I think that it still worth to point it out here:

the actual signing feature is implemented by the sign-addon dependency (github repo: https://github.com/mozilla/sign-addon), and so it may make sense to evaluate if it would be more reasonable to implement the new behavior inside the dependency.

[tomquas]

thx everybody, this is going in the right direction ;)

[diox]

Worth noting: under current limits, a single user can submit 3 add-ons per minute and 20 add-ons in an hour (and tbh I consider that generous, we might lower that, or introduce a limit per day as well). Another set of limits is added per IP. So don't expect fast builds if you're integrating that in your CI and try to sign more than 20 add-ons.