Converge action and gateway run-execution timeout/activity tracking

[marcusrbrown]

Summary

The action and the gateway each implement their own run-execution timeout/activity tracking, with no shared code. They've drifted, and #1055 widened the surface by adding a gateway-local inactivity timer that mirrors — but doesn't reuse — the action's pattern. Worth extracting a shared activity-timeout primitive so the two paths stop diverging.

Current state (two parallel implementations)

• Action (src/features/agent/): a poll watchdog + ActivityTracker — INITIAL_ACTIVITY_TIMEOUT_MS (90s startup-stall guard) in session-poll.ts, event-driven activity marking in streaming.ts, a 30-min hard wall-clock cap (DEFAULT_TIMEOUT_MS) in execution.ts. Completion keyed off session.idle.
• Gateway (packages/gateway/src/execute/): after Gateway operator runs can timeout after emitting valid output #1055, a resettable inactivity timer (GATEWAY_RUN_INACTIVITY_TIMEOUT_MS, 5 min) reset on every output event, paused during approval waits, combined with a 30-min hard ceiling (GATEWAY_RUN_TIMEOUT_MS) via AbortSignal.any, in run-core.ts. Completion keyed off session.idle.

Both consume the same OpenCode SSE event shapes and both center on session.idle, but the timeout machinery is duplicated. run-core.ts even carries a comment that it deliberately re-implements streaming.ts accessors locally because of a layer/import ban — so the divergence is partly structural.

Why it matters

• Two timeout models means two places to fix a timing bug, and they already disagree (the gateway shipped a pure 10-min wall clock for months while the action used 30-min + activity awareness — that gap was Gateway operator runs can timeout after emitting valid output #1055).
• The gateway's inactivity model is now arguably the better one; the action could adopt it.

Possible direction (to evaluate, not yet decided)

• Extract a small, dependency-free activity-timeout primitive (an inactivity timer with arm/reset/clear + a hard-ceiling composite signal, keyed off a generic "activity" signal) into a shared low-layer module both paths can import, respecting the existing layer rules. Keep session.idle-as-success and approval-pause semantics as caller concerns.
• Reconcile the constants (startup-stall window, inactivity window, hard ceiling) so the two surfaces have a documented, consistent policy.

Constraints

• The import-direction ban that forced run-core.ts to re-implement streaming.ts accessors must be respected — the shared primitive has to live at a layer both can depend on.
• No behavior change to the action path without its own tests; this is a refactor-for-convergence, so it needs to be behavior-preserving on both sides and verified independently.

Context

Split out from #1055, which added the gateway inactivity timer. Low priority — both paths work; this is about not maintaining two drifting copies.

[fro-bot]

Triage: Converge action and gateway run-execution timeout/activity tracking

Thanks for splitting this out. I dug into both code paths to verify the current state, and there's one important correction to the issue description before this becomes actionable.

TL;DR

• The action path matches the description: a 90s startup-stall guard + activity-driven watchdog + 30 min hard cap, completion keyed off session.idle. ✔️
• The gateway path does not yet have the inactivity timer the issue describes as "current state." On main, the gateway still uses a pure wall-clock (AbortSignal.timeout(remainingBudgetMs), default 10 min via GATEWAY_RUN_TIMEOUT_MS=600000). There is no resettable 5-min inactivity timer, no AbortSignal.any composite, and no approval-pause-aware reset.
• #1055 is an open issue, not a merged PR. It describes that pure-wall-clock behavior as a bug and proposes the inactivity timer as the fix. So the convergence target here is partly not-yet-built.

This reframes the work: it's less "merge two existing implementations" and more "build the gateway's activity model once, in a shared place, so the action can adopt it too."

What's actually in the code today

Action (src/features/agent/):

• INITIAL_ACTIVITY_TIMEOUT_MS = 90_000 — startup-stall guard (session-poll.ts:12, enforced at :185).
• ActivityTracker interface + event-driven marking on message.part.delta / session.next.* / token updates (streaming.ts:21-31, marking at :159/:244/:282).
• Hard wall-clock cap DEFAULT_TIMEOUT_MS = 1_800_000 (30 min), enforced via setTimeout→abortController.abort() (execution.ts:28-39).
• Completion: session.idle sets sessionIdle + currentTurnTerminalSignalReceived; poll resolves on that, with a session.status()==='idle' fallback (session-poll.ts:147-178, streaming.ts:306-315).

Gateway (packages/gateway/src/execute/):

• GATEWAY_RUN_TIMEOUT_MS default 600000 (10 min, not 30) — config.ts:498.
• Single hard abort: AbortSignal.timeout(remainingBudgetMs) where remainingBudgetMs = runTimeoutMs − elapsedSinceRunStart (run.ts:481-482). No AbortSignal.any.
• Approval deadline is derived from the same remaining budget and capped below the hard abort + below Discord's interaction-token expiry (computeApprovalDeadlineMs, run.ts:201-204).
• onActivity / onBusy hooks drive status UX (typing indicator, debounced status edits), not a timeout reset (run-core.ts:130/501/518, status-message.ts).
• Completion keyed off session.idle (run-core.ts:526-533); stream-close-before-idle → RunCoreError('stream-ended').

So both paths already key completion off session.idle — that part of the issue holds. The divergence is real, but the gateway's "better inactivity model" the issue references is still aspirational (tracked by #1055).

The import-ban constraint has a clean, already-existing answer

run-core.ts:19-21 documents why it re-implements streaming.ts accessors:

Event-stream semantics mirror src/features/agent/streaming.ts exactly. Cannot import from that module (backwards-dependency ban); accessors are replicated locally.

The good news: both surfaces already depend on @fro-bot/runtime, whose src/shared/ is Layer 0 (pure, no external deps). It's already the shared home for the very constant this issue is about:

• DEFAULT_TIMEOUT_MS lives in packages/runtime/src/shared/constants.ts:13.
• The action consumes it through a re-export shim (src/shared/constants.ts → export { DEFAULT_TIMEOUT_MS } from '@fro-bot/runtime').
• The gateway imports @fro-bot/runtime directly (run-core.ts:24).
• sleep is already shared the same way (runtime/src/shared/async.ts).

So a dependency-free activity-timeout primitive in @fro-bot/runtime/src/shared/ is importable by both paths without violating the backwards-dependency ban — no new layer required. This is the structural unlock the issue was looking for.

Reproduction

Not a runtime bug to reproduce — this is a refactor-for-convergence. I verified the divergence statically:

• Confirmed the gateway has no inactivity timer on main (grep for INACTIVITY/AbortSignal.any in packages/gateway/src/execute/ → only AbortSignal.timeout).
• Confirmed #1055 is an open issue (not a merged PR) proposing the inactivity model.
• Confirmed @fro-bot/runtime/shared is Layer 0 and already consumed by both surfaces.

Proposed next steps

Recommend sequencing this after (or alongside) #1055, since #1069 depends on the gateway model existing:

1. Resolve Gateway operator runs can timeout after emitting valid output #1055 first by building the inactivity model directly as the shared primitive — don't build it gateway-local and converge later. Land it in @fro-bot/runtime/src/shared/ (e.g. activity-timeout.ts): a dependency-free inactivity timer with arm/reset/clear + a hard-ceiling composite (AbortSignal.any([inactivity, AbortSignal.timeout(ceiling)])), keyed off a generic "activity" signal. Keep session.idle-as-success and approval-pause as caller concerns (the primitive exposes pause/resume; callers decide when).
2. Adopt in the gateway: replace the pure AbortSignal.timeout in run.ts/run-core.ts with the shared primitive; wire onActivity to reset() and approval-wait to pause(). This closes Gateway operator runs can timeout after emitting valid output #1055.
3. Adopt in the action: replace the bespoke watchdog in session-poll.ts/execution.ts with the same primitive — behavior-preserving, gated by its own tests (the issue's constraint). Keep INITIAL_ACTIVITY_TIMEOUT_MS (90s) as the action's startup-stall caller config.
4. Reconcile constants in one documented policy table: startup-stall window (90s, action-only), inactivity window (the Gateway operator runs can timeout after emitting valid output #1055 value), hard ceiling (action 30 min vs gateway 10 min — these currently disagree and should be reconciled explicitly, ideally both env-configurable with a shared default).
5. Tests on both sides independently, per the constraint — no action behavior change without action tests; gateway keeps its run-core/run timeout regression tests.

Suggested issue edits

• Update the "Current state" gateway bullet: the inactivity timer is proposed in Gateway operator runs can timeout after emitting valid output #1055, not shipped. Today the gateway is a pure 10-min wall clock.
• Change "Split out from Gateway operator runs can timeout after emitting valid output #1055, which added the gateway inactivity timer" → "Split out from Gateway operator runs can timeout after emitting valid output #1055, which proposes the gateway inactivity timer (still open)."
• Note the dependency: Converge action and gateway run-execution timeout/activity tracking #1069 is blocked on / should absorb Gateway operator runs can timeout after emitting valid output #1055's implementation rather than following it.

Severity/priority assessment matches the issue: low priority, no user-facing bug here (that's #1055's job) — this is purely about not maintaining two drifting copies, and the cleanest path is to never create the second copy in the first place.

---

Run Summary

Field	Value
Event	issues
Repository	fro-bot/agent
Run ID	28415971561
Cache	hit
Session	ses_0e9a91283ffeK9XFRtwySeaa7U

[marcusrbrown]

Re-triaging this — the earlier triage on this issue is stale and inverts the framing.

That triage was posted 2026-06-30 02:26Z and claimed "the gateway does not yet have the inactivity timer" and "#1055 is an open issue." Both were overtaken ~1h later: #1068 ("make operator run timeout activity-aware") merged 03:26Z and closed #1055. So the gateway inactivity model the triage described as not-yet-built has been on main for days.

Verified on current main:

• RunCoreErrorKind carries 'inactivity-timeout' (packages/gateway/src/execute/run-core.ts:42).
• The resettable inactivity timer composes with the hard ceiling via AbortSignal.any([signal, inactivityController.signal]) (run-core.ts:304), reset on every output event, paused during approval waits.
• run.ts composes its own run-level signals AbortSignal.any([timeoutSignal, cancelSignal]) (run.ts:612) and classifies inactivity-timeout on the error path (run.ts:796).

The issue body already reflects this post-#1055 reality — it's only the triage comment that's out of date. So the work here is not "build the gateway inactivity model first." That model exists. The remaining convergence is:

1. Extract the now-existing inactivity/activity-timeout machinery to a shared low-layer primitive both surfaces can import — @fro-bot/runtime/src/shared/ is Layer 0 (dependency-free) and already consumed by both the action (via a re-export shim) and the gateway (direct import), so a shared activity-timeout primitive there respects the import-direction ban that forced run-core.ts to re-implement streaming.ts accessors locally. No new layer needed.
2. Adopt it in the action as a behavior-preserving refactor, gated by the action's own tests (keep the 90s startup-stall window as action-only caller config).
3. Reconcile the constants (startup-stall window, inactivity window, hard ceiling) into one documented policy — the action and gateway both now use a 30-min ceiling, but the windows should be a single source of truth.

Still low priority — both paths work; this is anti-drift, not a bug. But whoever picks it up should start from "extract + adopt," not "build the gateway model."

@fro-bot please re-verify the gateway inactivity model exists on current main (run-core.ts inactivity controller + run.ts classification) and that #1055 is closed by #1068, then correct your triage framing accordingly.

[fro-bot]

Re-verified: the gateway inactivity model is live on main — my earlier triage framing was stale and is now corrected

You're right on every point. I re-ran the verification against current main and confirm my 2026-06-30 triage inverted the framing. Here's what I found:

#1055 is closed by #1068 (merged)

• Gateway operator runs can timeout after emitting valid output #1055 — state CLOSED, reason COMPLETED ("Gateway operator runs can timeout after emitting valid output").
• fix(gateway): make operator run timeout activity-aware #1068 — MERGED at 2026-06-30T03:26:21Z ("fix(gateway): make operator run timeout activity-aware"). Merged ~1h after my triage comment, which is exactly why my "not-yet-built" claim was overtaken.

The gateway inactivity model exists on current main

• RunCoreErrorKind carries 'inactivity-timeout' — packages/gateway/src/execute/run-core.ts:42 ("run exceeded the inactivity timeout (no text/tool progress)").
• Resettable inactivity timer composed with the hard ceiling via AbortSignal.any([signal, inactivityController.signal]) — run-core.ts:304; the timer arms only when inactivityTimeoutMs > 0 (:299-301) and resets via resetInactivity() (:291-297).
• run.ts composes run-level signals AbortSignal.any([timeoutSignal, cancelSignal]) — run.ts:612 — and run-core's inactivity AbortSignal.any nests cleanly on top (documented at :608-611).
• run.ts classifies the inactivity path on error: isInactivityTimeout = isCoreError && execError.kind === 'inactivity-timeout' — run.ts:796.

So the gateway's activity-aware timeout has been on main for days. My earlier "gateway is a pure 10-min wall clock / #1055 is open" framing is withdrawn.

Corrected framing for #1069

The issue body already reflects post-#1055 reality; only my triage comment was stale. The remaining work is extract + adopt, not "build the gateway model":

1. Extract the now-existing inactivity/activity-timeout machinery to a shared Layer-0 primitive in @fro-bot/runtime/src/shared/ (e.g. activity-timeout.ts): a dependency-free inactivity timer with arm/reset/clear + a hard-ceiling composite, keyed off a generic "activity" signal. This layer is already consumed by both surfaces — the action via a re-export shim, the gateway via direct import — so it respects the backwards-dependency ban that forced run-core.ts to re-implement streaming.ts accessors locally. No new layer needed.
2. Adopt in the action as a behavior-preserving refactor, gated by the action's own tests. Keep the 90s startup-stall window (INITIAL_ACTIVITY_TIMEOUT_MS) as action-only caller config.
3. Reconcile constants into one documented policy. Both surfaces now use a 30-min ceiling, so the hard-ceiling disagreement I flagged earlier is already resolved; the remaining single-source-of-truth work is the inactivity/startup-stall windows.

Priority unchanged: low — both paths work, this is anti-drift, not a bug. Whoever picks it up should start from "extract + adopt."

Thanks for the correction — the record is now accurate.

---

Run Summary

Field	Value
Event	issue_comment
Repository	fro-bot/agent
Run ID	28702664004
Cache	hit
Session	ses_0d36d8124ffeVYpzfXQO6ZDmAX

[marcusrbrown]

Dashboard visibility for the timeout/activity failure kinds is now satisfied. fro-bot/dashboard#174 shipped operator contract 1.6.0 support and release 2026.07.11 is deployed; inactivity-timeout and the other sanitized failureKind values now render as operator-facing labels. This issue remains scoped to upstream action/gateway timeout-code convergence, not dashboard UI.