Describe the bug
Summary
Ran pitstop-check against the Weave Node SDK and found the same retry classification gap in two files:
sdks/node/src/clientApi.ts:108 — 429 without Retry-Aftersdks/node/src/utils/retry.ts:15 — 429 without Retry-After, all 429s treated as retryable
The problem
Different 429s require different handling:
- Transient pressure → wait and retry
- Concurrency pressure → reduce parallelism before retry
- Quota / billing exhaustion → do not retry
When these get collapsed into one retry branch, systems amplify pressure instead of absorbing it.
The gap in retry.ts is the more significant finding — that's the shared primitive. Any caller that routes through it inherits the misclassification.
Why this matters for Weave
Weave traces LLM calls at volume. When those calls hit a quota exhaustion 429 and the SDK retries instead of
surfacing immediately, the tracing layer amplifies the failure rather than capturing it cleanly.
Example
curl -s -X POST https://web-production-273d3.up.railway.app/classify \
-H "Content-Type: application/json" \
-d '{"status":429,"headers":{"retry-after":"600"},"provider":"anthropic"}'Returns STOP — quota exhaustion, do not retry.
The same status with retry-after: 30 returns WAIT.
Status alone is insufficient for the decision.
Static check
pitstop-check sdks/node/src
Run via github.com/SirBrenton/pitstop-check
Weave Project Link
No response
Screenshots
No response
Describe the bug
Summary
Ran
pitstop-checkagainst the Weave Node SDK and found the same retry classification gap in two files:sdks/node/src/clientApi.ts:108— 429 without Retry-Aftersdks/node/src/utils/retry.ts:15— 429 without Retry-After, all 429s treated as retryableThe problem
Different 429s require different handling:
When these get collapsed into one retry branch, systems amplify pressure instead of absorbing it.
The gap in
retry.tsis the more significant finding — that's the shared primitive. Any caller that routes through it inherits the misclassification.Why this matters for Weave
Weave traces LLM calls at volume. When those calls hit a quota exhaustion 429 and the SDK retries instead of
surfacing immediately, the tracing layer amplifies the failure rather than capturing it cleanly.
Example
Returns
STOP— quota exhaustion, do not retry.The same status with
retry-after: 30returnsWAIT.Status alone is insufficient for the decision.
Static check
Run via
github.com/SirBrenton/pitstop-checkWeave Project Link
No response
Screenshots
No response