-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
consolidate/refactor submission throttles #8511
Comments
@eviljeff does this issue affect only addon submission throttling or every other API throttling we have in place? |
The refactoring touched devhub and the existing addon signing api (used by webext) as well as the new addon submisison API - there shouldn't be any changes in what's enforced though. And the throttle limits are supposed to be shared across all methods (addon signing API; devhub submission of a validated upload; addon submission API with a validated upload). |
@eviljeff I've verified this issue on stage where rate limiting is active. I've created submissions from Devhub, the signing API and the new addons submission API. My results are as follows: User restrictions:
IP restrictions:
With regards to the new addon submission API, we don't seem to have any rate limit for the |
I deliberately didn't add any, because a user could end up having to submit multiple uploads if they didn't test with the linter before submission, or for non-linter validation error, so the existing limits would be too low. But we potentially should have_some_ throttling - could you file a follow-up issue to look into it? |
currently some of our logic for throttling submissions is contained in VersionView().check_throttles itself, which makes it difficult to reuse in other classes. We should rewrite it into either a utility function, or entirely within DRF throttle classes that can be reused more easily.
The text was updated successfully, but these errors were encountered: