3 ms·
Which is why your test integration environment has to throw 429 and 5xx errors consistently from day one. The error handling paths are hard to retrofit but easy
by lanstin 3y ago
Which is why your test integration environment has to throw 429 and 5xx errors consistently from day one. The error handling paths are hard to retrofit but easy to do before deployment.
- o11c 3y ago(What test environment?) That will make you introduce error handling, but not necessary "correct" handling. "Retry after errors" is a great way to overload a system.
- lanstin 3y agoThe idea behind forcing your clients to handle 429 isn't because they will do the right thing (although you'd think since ethernet won with exponential and random backup with some max timeouts that would be the default) but because it allows you the flexibility server side to start returning 429s when you need to - maybe just based on some idea of server load, maybe as some way of hard rate limits for a certain caller ID, maybe to do maintenance, whatever. It's the semantics "not processed, not fatal, try again in the future" which is hard to shoe horn into a large deployed number of callers after the fact, without angering people.
- hinkley 3y agoWe have some people who are convinced that Google is punishing us for 429 responses. If that's true, then it sucks the big one.