set a custom error on 429; affects [matrix twitch weblate] #9159
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chris48s
added
the
service-badge
|
|
Had a quick chat about this today. Decided we are going to make it global (even if its our api key) and message should be "rate limited by upstream service" Also consider impact on.. |
Interesting. The Twitch one raised my eye 👀 |
chris48s
changed the title
|
Yeah that twitch code is.. exciting. The changes in this PR don't change anything about the way that code works. If we get a 429, we will still throw an |
calebcartwright
approved these changes
May 18, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a follow up to #9155 but it is also the starting point of a slightly wider conversation.
I think I'm fairly convinced that this is a good idea for services where the user supplies an API key and we should actually do this on other services following this pattern. One thing I would quite like to do though is see if we can come up with a way to express this that clarifies that it is not us who has applied the rate limit and succinctly communicate that the rate limit which has been exceeded is that of the upstream service/user's API key, not shields.io.
In principle, we could set a custom error like this one level up (so it applies to all badges). 429 always means "too many requests". I'm slightly in 2 minds about this though. For services where the api key is supplied by the user this feels like more useful information/more likely to be actionable in some way. For a service that relies on anon access or a key we hold "centrally", its not really an actionable error. That said, its probably at least more informative. Any thoughts on this?