Chain triggers time out against busy orchestrator sessions — default 5-min idle wait too short, 10-min MAX_TRIGGER_TIMEOUT cap also marginal

[JeanBaptisteRenard]

Context

The trigger-watcher's chain triggers ({"chain":[...],"wait":"idle"}) wait for the target session to become idle before injecting each step. Two limits govern this wait:

• default per-step idle timeout: 300 000 ms (5 min)
• hard cap: MAX_TRIGGER_TIMEOUT = 600_000 (trigger-watcher.js:38) — any timeout_ms above 10 min is rejected with invalid step timeout_ms

Problem

Busy orchestrator sessions (the primary consumer of chain triggers, e.g. the auto-compact FORCE path: /compact → resume prompt) frequently never reach 5 consecutive minutes of idle: background sub-agent notifications, cron ticks, and tool results keep re-waking them. The chain then fails silently from the session's point of view.

Witnessed (2026-06-05 ~20:00 UTC+2)

1. Auto-compact chain dropped against an active orchestrator session →
   {"ok":false,"error":"chain timeout","steps_completed":0,"total_waited_ms":300290}
   — correct session targeted, but never idle ≥5 min.
2. Re-drop with timeout_ms: 1800000 → rejected (invalid step timeout_ms, cap is 600 000).
3. Re-drop at the 600 000 cap succeeded (steps_completed:2, total_waited_ms:150198) — but only because the session deliberately went quiet (no crons/agents running). Without that cooperation, even 10 min is marginal for a session with periodic background activity.

Suggestions (any subset)

• Raise the default per-step timeout for chain steps (e.g. 10 min), since chains are typically dropped by the session itself expecting eventual delivery.
• Raise or make configurable MAX_TRIGGER_TIMEOUT (e.g. 30–60 min) — a chain that fires late is almost always better than one that dies silently.
• Alternative/complement: an "expire":"never"-style mode where the chain persists until the session is next idle, however long that takes (with the existing processed/result.json audit trail).
• On chain timeout, consider re-queueing once instead of discarding — the failure mode today is fully silent for the target session (only discoverable by reading processed/*.result.json).

[JeanBaptisteRenard]

Correction on the report above, after reading the watcher source more carefully (verified against trigger-watcher.js):

• The working knob is the top-level trigger.timeout_ms — it sets the global chain deadline (resolvedTimeoutMs → globalTimeout).
• A per-step timeout_ms is capped by the global deadline (Math.min(step.timeout_ms, globalDeadline - Date.now())) and is therefore inert on its own: with the 300 s default global deadline, Math.min(600000, ~300000) = 300000.
• So in my step 3 above, the retry succeeded because the session went quiet within the window — the per-step timeout_ms: 600000 it carried had no effect. The correct form is {"sessionId":…,"timeout_ms":600000,"chain":[…]}.
• The two rejection strings are distinct: invalid timeout_ms (top-level) vs step[N]: invalid step timeout_ms (step field).

The suggestions stand unchanged (raise default / configurable cap / persist-until-idle), but the docs-level mitigation is: top-level timeout_ms at the cap, not per-step.