persist sessionId on failure so a failed run stays resumable#47
persist sessionId on failure so a failed run stays resumable#47matt-wright86 wants to merge 1 commit into
Conversation
runTaskAgent persisted the engine sessionId only after the success/failure branch, so a failed run lost its session and a retry had to rebuild context from scratch. Persist it before the branch, and return telemetry on the failure path too. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe ChangesSession persistence and telemetry on failure
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@orchestrator-v2/packages/agent-3-task/src/run-task-agent.ts`:
- Around line 51-58: The unguarded ctx.setState call in runTaskAgent can now
fail the whole function on both success and failure paths, so wrap the
persistence step in try/catch and keep returning a structured WorkItemResult if
state saving rejects. Use the existing runTaskAgent flow and the
engineResult.sessionId / ctx.setState block to locate the change, and make sure
any persistence error is handled without throwing past the function boundary.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: b73d428d-7978-42eb-89b0-4759a9fc82f0
📒 Files selected for processing (2)
orchestrator-v2/packages/agent-3-task/src/run-task-agent.spec.tsorchestrator-v2/packages/agent-3-task/src/run-task-agent.ts
| // Persist the sessionId before branching on the outcome, so a failed run stays | ||
| // resumable — a retry can --resume instead of rebuilding context from scratch. | ||
| if (engineResult.sessionId !== undefined) { | ||
| await ctx.setState({ | ||
| ...workItem.state, | ||
| sessionId: engineResult.sessionId, | ||
| }); | ||
| } |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Unhandled ctx.setState failure now impacts both success and failure paths.
This persistence call isn't wrapped in try/catch. If ctx.setState rejects, the function throws instead of returning a structured WorkItemResult, defeating the purpose of making failed runs resumable. Since this block now runs unconditionally (previously only on the success path), the blast radius of an unhandled rejection here has doubled.
🛡️ Suggested guard
if (engineResult.sessionId !== undefined) {
- await ctx.setState({
- ...workItem.state,
- sessionId: engineResult.sessionId,
- });
+ try {
+ await ctx.setState({
+ ...workItem.state,
+ sessionId: engineResult.sessionId,
+ });
+ } catch {
+ // Swallow persistence errors so a failing setState doesn't crash the run;
+ // resumability is best-effort and shouldn't mask the underlying engine result.
+ }
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // Persist the sessionId before branching on the outcome, so a failed run stays | |
| // resumable — a retry can --resume instead of rebuilding context from scratch. | |
| if (engineResult.sessionId !== undefined) { | |
| await ctx.setState({ | |
| ...workItem.state, | |
| sessionId: engineResult.sessionId, | |
| }); | |
| } | |
| // Persist the sessionId before branching on the outcome, so a failed run stays | |
| // resumable — a retry can --resume instead of rebuilding context from scratch. | |
| if (engineResult.sessionId !== undefined) { | |
| try { | |
| await ctx.setState({ | |
| ...workItem.state, | |
| sessionId: engineResult.sessionId, | |
| }); | |
| } catch { | |
| // Swallow persistence errors so a failing setState doesn't crash the run; | |
| // resumability is best-effort and shouldn't mask the underlying engine result. | |
| } | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@orchestrator-v2/packages/agent-3-task/src/run-task-agent.ts` around lines 51
- 58, The unguarded ctx.setState call in runTaskAgent can now fail the whole
function on both success and failure paths, so wrap the persistence step in
try/catch and keep returning a structured WorkItemResult if state saving
rejects. Use the existing runTaskAgent flow and the engineResult.sessionId /
ctx.setState block to locate the change, and make sure any persistence error is
handled without throwing past the function boundary.
Summary
runTaskAgentpersisted the enginesessionIdonly after the success/failurebranch, so a failed run lost its session — a retry had to rebuild context from
scratch. Persist it before the branch (failed runs stay resumable), and
return telemetry on the failure path too.
Type of change
Checklist
go/npxwere not usedmakegates — N/A:orchestrator-v2uses its ownvptoolchainvp run -r buildclean ·vp run -r testgreensessionIdpersisted + telemetry returned)main/simplify)Notes for reviewers
First of the orchestrator-v2 hardening pieces (from the earlier experiment branch)
re-expressed onto the work-item model as focused PRs. Next up: I3 (callback
resilience), Route A (telemetry as a terminal outcome), I1 (capability routing).
🤖 Generated with Claude Code