Show HN: Pitstop-check – finds the retry bug that turns 429s into request storms
4 コメント
If you want to try it on your own code: npx pitstop-check ./src — no config, no install. Works on any TS/JS repo. Happy to answer questions about the pattern or false positives.
Cool stuff.
Thanks Rahmi — saw EZThrottle a while back, been thinking about how the layers relate. Your coordinated retry layer assumes the failure is classified correctly upstream — that’s the gap I’ve been working on.
Would be curious if you’re seeing cases where region racing picks the wrong route because the original 429 was misclassified.
Would be curious if you’re seeing cases where region racing picks the wrong route because the original 429 was misclassified.
Ezthrottle works by sending the request and depending on what error code the user wishes to reroute on, it will send to another region. It give the user a chance to say something different in case the api misclassifies the error. The user would have to tune it.
Looks fine at first. Under load it turns rate limits into request storms.
I wrote a small CLI to catch it:
It scans TS/JS and flags things like:
Example (ran against OpenClaw):
The retry primitive supports Retry-After. The callers just don’t wire it up.
So when the API returns Retry-After: 600, the client retries on its own schedule instead of backing off.
What’s going on is basically collapsing different failure modes into one:
Most code just does:
The tool is heuristic (will flag some test files), but it’s been useful for quickly spotting this in real repos.
https://github.com/SirBrenton/pitstop-check