fix(client): treat any 4xx on stop as already-stopped, not an error#12
Open
derencius wants to merge 3 commits into
Open
fix(client): treat any 4xx on stop as already-stopped, not an error#12derencius wants to merge 3 commits into
derencius wants to merge 3 commits into
Conversation
cancel_workflow only swallowed 404/410 and re-raised other client errors. A 400 (run already terminal on the API) escaped as a raw Faraday::BadRequestError, which isn't an OutputWorkflows::APIError — so a caller that rescues APIError (e.g. cancelling a concurrent execution before dispatch) missed it and failed. Any 4xx on the stop call means the run can't be stopped (terminal, gone, or expired) — functionally already stopped — so return false instead of raising. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Codex review flagged the catch-all 4xx -> false as too aggressive: a 401 (expired auth), 403 (forbidden), 408, or 429 (rate limit) on /stop would be silently swallowed as a successful no-op, hiding real auth/quota failures and recording a misleading terminal local state. Narrow to ALREADY_STOPPED_STATUSES (400/404/409/410 — the terminal/gone/ expired cases). Every other Faraday error routes through handle_faraday_error and surfaces as OutputWorkflows::APIError, so the caller's rescue catches it instead of dying on a raw Faraday error. Add tests asserting 401/403/408/429 raise APIError. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The .codex-feedback--* pattern is already covered by the global gitignore; no need for a repo-level entry. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
cancel_workflowonly treated 404/410 as "already stopped" and re-raised every other client error. The API returns 400 when a run is already in a terminal state — that escaped as a rawFaraday::BadRequestError, which isn't anOutputWorkflows::APIError, so callers that rescueAPIError(e.g. cancelling a concurrent execution before dispatch) missed it and failed.Fix
Allowlist the statuses the stop endpoint returns when a run genuinely can't be stopped —
400, 404, 409, 410(terminal / gone / expired) — and returnfalsefor those. Every other error (401 auth, 403 forbidden, 408, 429 rate limit, 5xx, network) routes throughhandle_faraday_errorand surfaces asOutputWorkflows::APIError, so the caller's rescue catches it instead of dying on a raw Faraday error — and real auth/quota failures aren't silently swallowed as a successful no-op.Review
Codex review flagged an earlier "all 4xx → false" version as too aggressive (it would have masked 401/403/429). Narrowed to the allowlist per that feedback.
Testing
400/404/409/410returnfalse;401/403/408/429raiseAPIError(TDD red/green).🤖 Generated with Claude Code