Repository navigation
End a flows tool call before the shortest harness timeout - #1097
alexeyzimarev merged 4 commits into
Conversation
Codex aborts an MCP tool call at 300 s, and an aborted start never hands the driver its flow_run_id. The 3-minute settlement window is one cycle of the server's reconcile sweep and cannot shrink, so the absolute settlement cap keeps only 30 s above it. The bounds apply to every harness, not per client. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
PR Summary by QodoEnd flow tool calls before harness timeouts
AI Description
Diagram
High-Level Assessment
Files changed (9)
|
Code Review by Qodo
1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| /// daemon-lane progress can re-arm <see cref="SettlementElapsedDeadline"/> indefinitely, so this | ||
| /// is what bounds the lane. Stays under <see cref="ToolCallBudget"/> so that a start admitted at | ||
| /// the last moment still has time to return its flow_run_id.</summary> | ||
| internal static readonly TimeSpan SettlementAbsoluteDeadline = TimeSpan.FromSeconds(210); |
There was a problem hiding this comment.
4. Server recovery outlasts retry window 🔗 Cross-repo conflict ☼ Reliability
SettlementAbsoluteDeadline assumes the server’s three-minute sweep interval completes recovery within 210 seconds, but that interval precedes several sequential passes and the heal-convergence pass alone has a further 30-second budget. When participant_unreachable requires durable-proof convergence, a retry arriving after the relevant pass can hit the new ceiling before the next pass repairs the role, so the CLI returns a settlement-busy result instead of completing the retry.
Agent Prompt
## Issue description
The CLI now gives server-side heal convergence only 210 seconds, but the server waits three minutes before beginning a sequential reconciliation sweep and does not guarantee that the required pass finishes within the remaining 30 seconds.
## Fix Focus Areas
- src/Capacitor.Cli/Commands/McpFlowsServer.cs[505-521]
- /cross_repos/kcap-server/src/Capacitor.Server/Flows/FlowReconcilerService.cs[316-369]
- /cross_repos/kcap-server/src/Capacitor.Server/Flows/FlowReconcilerService.cs[1447-1451]
## Recommended Fix
Coordinate a kcap-server change that triggers or prioritizes heal convergence when durable absence evidence arrives, with an end-to-end test proving `participant_unreachable` becomes retryable within 210 seconds. Keep the CLI ceiling only after that server timing guarantee exists; otherwise use a protocol that returns a recoverable flow identifier without waiting for convergence.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
There was a problem hiding this comment.
Not changed by this PR. participant_unreachable carries no last_processed_seq, so its window never re-arms and it exhausts at the flat SettlementElapsedDeadline — 3 minutes before this change and after it. The 210 s SettlementAbsoluteDeadline only ever clips the seq-re-armed path. The underlying observation is fair: the server sleeps 3 minutes between sweeps, so a retry that starts just after one can miss the next by the length of a sweep. It then gets the retryable error and succeeds on the next attempt. Widening that window is a separate decision; the doc comment no longer claims the window covers a full sweep cycle.
It is one POST outside the settlement-retry lane, so that lane's deadline never reaches it, and the shared client has no timeout of its own. It cannot be re-sent: a second POST would mint and launch a second run. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…exeyzimarev/ai-3075-flows-survive-harness-tool-timeout # Conflicts: # docs/CHANGES.md
1 participant
Part of #1095 — AI-3075
What & why
Codex aborts an MCP tool call at 300 s. A flows call is bounded at 9 minutes, so on Codex a round over five minutes ends in the harness's own timeout error, and an aborted
start_review_flownever hands the driver itsflow_run_id. The bounds now fit under 300 s for every harness, so the call ends on the benign "Flow still running" reply, id included.ToolCallBudgetPollCap,SettlementAbsoluteDeadlineSettlementElapsedDeadlineWhere to look
SettlementElapsedDeadlinestays at 3 minutes: it is one cycle of the server's reconcile sweep, which is what lets aparticipant_unreachableretry succeed. The absolute settlement cap therefore sits 30 s above it, so a daemon lane that keeps making progress re-arms the window for 30 s before the caller gets the retryable busy error — on Claude Code too. #1095 stays open for the recoverable id, the Codextool_timeout_secand the timeout guidance.Verification
Expected to be less than 00:05:00 but received 00:09:35(start) and00:08:35(wait: true). Both pass with the change.dotnet run --project test/Capacitor.Cli.Tests.Unit/Capacitor.Cli.Tests.Unit.csproj→ total 4611, failed 1:session_start_omits_workspace_root_when_cwd_has_no_git_repo, which passes run alone.dotnet publish src/Capacitor.Cli/Capacitor.Cli.csproj -c Release 2>&1 | grep -E 'IL[23][01][0-9]{2}'→ no output.🤖 Generated with Claude Code