Context
While running a multi-step mission (tole run on develop @ 0c424bf, provider: bifrost, model glm/glm-5.3), the gateway returned intermittent 502s. Each occurrence aborted the in-flight turn, and the durable session became undriveable without a recovery dance:
tole: provider failed: http status: 502 (resume with: tole resume s-…)
$ tole resume s-… "continue" # → refused
tole: invalid commit: run_turn requires pc Idle or Final, found Planning
Actual behavior
- A provider failure mid-turn leaves the state machine at
pc=Planning.
resume <id> [PROMPT] refuses to run a new turn until the interrupted turn is resolved; the only resolution path is the approvals-only resume (resume <id> with no prompt), which is interactive (stdio prompt) and auto-denies without a TTY.
- When the interrupted turn had a pending tool intent, the recovery replays it; if the recorded intent was itself malformed (see the missing-
arguments issue — recorded as input: {}), the replay calls the tool with empty input up to the loop-guard limit and wedges the session again.
- Net effect: a transient upstream 502 can permanently strand a session; the only escape observed was abandoning it and starting a fresh
run.
Expected behavior
A transient provider error should settle the turn into a resumable state (e.g. commit the failure as an error result, land on pc=Idle/Final), so a plain tole resume <id> "continue" just works — matching the E5 crash-resume guarantee ("headless flows can continue a mission").
Suggestions
- On
ProviderError mid-turn, settle the turn (record the provider failure as a tool-result-equivalent entry) so pc returns to a resumable position.
- Make the approvals-only recovery non-interactive-friendly (e.g.
--yes/--allow respected during recovery, or a non-TTY default of "skip pending op with an error result" instead of deny-and-wedge).
- Guard the recovery replay against malformed pending intents (empty input) — settle them as errors instead of executing.
Evidence
Sessions s-1a0b1fa8782-381c, s-1a0b200fc4d-3c20, s-1a0b2035ad4-3d1a under /tmp/vetio-tole-test/tole-sessions/ all ended wedged at pc=Planning after 502s (bifrost gateway, 2026-09-18).
Context
While running a multi-step mission (
tole runon develop @0c424bf, provider: bifrost, model glm/glm-5.3), the gateway returned intermittent502s. Each occurrence aborted the in-flight turn, and the durable session became undriveable without a recovery dance:Actual behavior
pc=Planning.resume <id> [PROMPT]refuses to run a new turn until the interrupted turn is resolved; the only resolution path is the approvals-only resume (resume <id>with no prompt), which is interactive (stdio prompt) and auto-denies without a TTY.argumentsissue — recorded asinput: {}), the replay calls the tool with empty input up to the loop-guard limit and wedges the session again.run.Expected behavior
A transient provider error should settle the turn into a resumable state (e.g. commit the failure as an error result, land on
pc=Idle/Final), so a plaintole resume <id> "continue"just works — matching the E5 crash-resume guarantee ("headless flows can continue a mission").Suggestions
ProviderErrormid-turn, settle the turn (record the provider failure as a tool-result-equivalent entry) sopcreturns to a resumable position.--yes/--allowrespected during recovery, or a non-TTY default of "skip pending op with an error result" instead of deny-and-wedge).Evidence
Sessions
s-1a0b1fa8782-381c,s-1a0b200fc4d-3c20,s-1a0b2035ad4-3d1aunder/tmp/vetio-tole-test/tole-sessions/all ended wedged atpc=Planningafter 502s (bifrost gateway, 2026-09-18).