Post the triage "starting work" ack deterministically - #210
Merged
Conversation
… 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 genuineremote-control-urlprogress 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'sonRunningcallback 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 throughrunTurnbutrelayAndReplypassedundefinedfor 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
server.test.tscases:npx vitest runinapps/integration-gateway— 299/299 passing.npx tsc --noEmitinapps/integration-gateway— clean.