fix(runner): stop reading a spend-limit refusal as retryable - #1540
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Essentials Run ID: 📒 Files selected for processing (12)
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review. WalkthroughThe CLI adds public exit code Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The change makes spend-limit and authentication failures return their intended exit codes instead of being treated as transient runner failures. No actionable merge-blocking risk remains beyond normal checks and review. Sequence Diagram(s)sequenceDiagram
participant Runner
participant QA Wolf API
participant describeRequestError
participant CLI
Runner->>QA Wolf API: Send request
QA Wolf API-->>Runner: HTTP 402 payment refusal
Runner->>describeRequestError: Describe response
describeRequestError-->>Runner: Payment message and exit code 7
Runner-->>CLI: Return failure with exit code 7
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
Full details: Description checkExplanation The description includes the required Overview of Changes, Testing, and Checklist sections. It explains the 402 and 401 exit-code changes, lists concrete verification commands, and confirms the checklist items. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
3ff586d to
0eec92a
Compare
Overview of Changes
Today the four runner handlers rebuild every platform failure with exit code 4, documented as "Apex unreachable" - so an agent driving the CLI reads a spend-limit refusal as transient and retries forever. 402 now gets its own documented exit code, 7
payment, assigned indescribeRequestErrornext to the existing 401 → 3 mapping, and the handlers keep an exit code the platform layer already set instead of overwriting it with 4.The server's own reason ("You have reached your monthly limit of …") already travels in the error body and still does.
Also: the same overwrite was clobbering the 401 → 3 mapping on these four verbs, a 401 on
runner runexited 4. It exits 3 now.Testing
bun run typecheck bun run lint bun run format:check bun run knip bun run test bun run buildAll green locally. New cases:
describeErrors.test.tscovers the 402 mapping,evaluateSnippet.spendLimit.test.tsandimportPackage.test.tsprove the exit code survives the handlers' rebuild.Checklist