fix(work): stop killing headless SDD dispatches at a 300s idle-timeout - #549
Conversation
Headless CLI agents run in print mode and emit no incremental stdout — only one blob once the whole turn finishes — so idle detection can't tell a hung process from one legitimately still computing (e.g. a cargo build/test mid-turn). DEFAULT_IDLE_TIMEOUT_SECS defaulted to 300, so any real SDD turn taking longer than 5 minutes died every time, confirmed live via items #143/#150/#151 failing identically 8 times in a row. It now defaults to the same 21600s (6h) ceiling as --timeout, the only backstop that still means what its doc comment says. Agentflare-Agent: claude-code Agentflare-Branch: task/143-idle-timeout-inherit-hard-cap Agentflare-Item: 143
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
Included review availability: 0 reviews are currently available. Based on recent review activity, included reviews refill at 2 per hour. 📝 WalkthroughWalkthroughThe CLI now sets the default idle timeout to six hours, matching the hard timeout. Help text explains headless-agent output behavior and the risks of shorter idle timeouts. ChangesCLI timeout alignment
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The change aligns the default idle timeout with the existing six-hour hard cap so headless work executions are not stopped during legitimate long-running turns; no actionable merge-blocking risk remains after normal checks and review. Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Summary
DEFAULT_IDLE_TIMEOUT_SECSdefaulted to 300s and was used unconditionally byWorkItemExecutor::execute(the daemon's own in-process SDD dispatch path), independent of the 21600s (6h) hard-cap timeout.cargo build/cargo testmid-turn).DEFAULT_IDLE_TIMEOUT_SECSnow equalsDEFAULT_TIMEOUT_SECS(6h) instead of a separate, much shorter value — the hard-cap timeout remains the real backstop against a genuinely runaway process.--idle-timeoutis still available as an explicit opt-in for callers who know their agent/mode actually streams output.Test plan
cargo build -p agentflare --bin agentflare— cleancargo test -p agentflare --bin agentflare cli::work::— 43/43 passingcargo test -p agentflare --bin agentflare idle_timeout— existing idle-timeout unit tests still pass (they pass explicit durations, unaffected by the constant change)cargo fmt --check— cleanSummary by CodeRabbit