Skip to content

Post the triage "starting work" ack deterministically - #210

Merged
imaustink merged 1 commit into
mainfrom
fix/triage-deterministic-starting-comment
Aug 17, 2026
Merged

Post the triage "starting work" ack deterministically#210
imaustink merged 1 commit into
mainfrom
fix/triage-deterministic-starting-comment

Conversation

@imaustink

Copy link
Copy Markdown
Owner

Summary

Fixes: a labeled issue/PR triage run just launched an AgentRun Job in the cluster with no acknowledgement comment posted on the ticket at all.

relayAndReply (apps/integration-gateway/src/server.ts) only ever posts an upfront comment when a genuine remote-control-url progress event arrives from the delegated agent (onRemoteControlUrl, from commit c49a533). That was a deliberate call at the time — it stopped a stale session-page link from appearing on every run regardless of whether Remote Control actually worked. But the flip side: if that event never arrives (Remote Control not configured for the Agent, the CLI never hands back a session, or the agent fails before reaching that point), no comment posts at all, even though the run visibly launched a Job — which is exactly what we just observed against the live cluster.

Fix

orchestratorClient.invoke's onRunning callback already exists for precisely this case: it fires deterministically off this gateway's own poll of the turn's status (the moment it's genuinely running, past any identity-link pre-flight) — independent of anything the delegated agent itself does or doesn't emit. It was already threaded through runTurn but relayAndReply passed undefined for it.

Restored it as a plain, deterministic ack: "🤖 Starting work on this now." — no link, so nothing about it depends on Remote Control succeeding. The Remote Control URL, when one does arrive, now posts as its own separate follow-up comment ("🤖 Watch live or take over the session here: <url>") rather than being combined into one comment as before — the two signals are independent and shouldn't block on each other.

Test plan

  • Updated/added server.test.ts cases:
    • the default (no Remote Control URL ever arrives) case now expects the deterministic ack + final result (2 comments), not silence.
    • the Remote Control URL case now expects the ack and the URL as separate comments.
    • the deferred-ack/auto-resume suite's resumed-turn cases now expect the ack between the auth prompt and the final result (3 comments total).
  • npx vitest run in apps/integration-gateway — 299/299 passing.
  • npx tsc --noEmit in apps/integration-gateway — clean.

… Remote Control

relayAndReply only ever posted an upfront comment when a genuine
remote-control-url progress event arrived from the delegated agent
(c49a533) -- a deliberate call at the time, to stop a stale session-page
link from appearing on every run regardless of whether Remote Control
worked. But it also meant NO comment posts at all whenever that event
never arrives: not configured for the Agent, the CLI never hands back a
session, or the agent fails before reaching that point. A labeled issue
visibly launches an AgentRun Job with no acknowledgement on the ticket
at all in that case -- observed directly against the live cluster,
where the triage flow launched the agent but the ticket got no comment.

`orchestratorClient.invoke`'s `onRunning` callback already exists for
exactly this: it fires deterministically off this gateway's own poll of
the turn's status (the first time it's genuinely running, past any
identity-link pre-flight), independent of anything the delegated agent
does. It was already wired through `runTurn` and unused by
`relayAndReply` -- restored here as a plain "🤖 Starting work on this
now." ack with no link to depend on, posted separately from (and
independent of) the Remote Control follow-up comment.
@imaustink
imaustink merged commit 4bbf31c into main Aug 17, 2026
6 checks passed
@imaustink
imaustink deleted the fix/triage-deterministic-starting-comment branch August 17, 2026 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant