#21115: fix(agent): immediately abort active run on stop/abort message during…

Summary Problem: Stop/abort messages sent via Telegram (or any channel) while the agent is mid-generation were silently enqueued as normal followup runs and only processed after the current run finished — making them useless as interrupts. Why it matters: Users had no way to halt a runaway or misdirected agent from the chat interface; they had to switch to the dashboard to manually abort, which is slow and breaks the UX flow. What changed: In agent-runner.ts, before enqueuing a followup run, we now check if the incoming prompt is an abort trigger. If it is, we immediately call abortEmbeddedPiRun, clear all session queues, stop any running subagents, and return an acknowledgement reply instead of queuing. What did NOT change: Normal (non-abort) followup runs continue to enqueue exactly as before. No changes to gateway routing, channel adapters, or any other part of the system. Change Type Bug fix Scope Gateway / orchestration Linked Issue/PR Closes #20600 User-visible / Behavior Changes Users who send "stop", "abort", or a recognized interrupt keyword via Telegram (or any supported channel) while the agent is actively generating will now receive an immediate acknowledgement and the agent will halt. Previously the agent would continue and only process the stop message after completing its run. Security Impact New permissions/capabilities? No Secrets/tokens handling changed? No New/changed network calls? No Command/tool execution surface changed? No Data access scope changed? No Repro + Verification Environment OS: Windows 11 (WSL2 / Ubuntu) Runtime/container: Node.js Model/provider: claude-opus-4-5 Integration/channel: Telegram Relevant config: Default session/queue settings Steps Start a conversation with an agent via Telegram Send a message that triggers a long-running response (e.g., multiple tool calls or a research task) While the agent is generating, send "Stop" or "STOP" via Telegram Observe the agent behaviour Expected Agent halts immediately upon receiving the stop message User receives an abort acknowledgement reply No further queued responses are processed Actual (before fix) Agent continues generating and completes its run Stop message is processed as a new turn after generation finishes User must use the dashboard to abort manually Evidence Failing test/log before + passing after Trace/log snippets — Gateway logs confirmed long-running sessions (569s) with no evidence of stop messages being processed mid-run Screenshot/recording Perf numbers Human Verification Verified scenarios: Abort keyword sent mid-generation correctly halts the run, clears queues, stops subagents, and returns acknowledgement reply Edge cases checked: Non-abort followup messages still enqueue normally; sessionId null case handled with ?? "" What I did not verify: Behaviour across all supported channels beyond Telegram; edge cases where multiple stop messages are sent in rapid succession Compatibility / Migration Backward compatible? Yes Config/env changes? No Migration needed? No Failure Recovery How to disable/revert: Revert the changes to src/auto-reply/reply/agent-runner.ts — specifically remove the isAbortRequestText check block added before enqueueFollowupRun Files/config to restore: src/auto-reply/reply/agent-runner.ts only Known bad symptoms to watch for: If abort messages start incorrectly halting legitimate runs, check the isAbortRequestText matching logic in abort.ts Risks and Mitigations Risk: isAbortRequestText may match legitimate messages that happen to contain stop-like keywords in certain languages or contexts Mitigation: The matching logic lives in abort.ts and can be tightened independently without touching this fix. Scope is limited to the enqueue decision point only. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds immediate abort logic for stop/abort commands during active agent generation. Before the incoming abort message is enqueued as a followup run, the code now checks `isAbortRequestText`, and if true, immediately calls `abortEmbeddedPiRun`, clears session queues, stops any subagents, and returns an acknowledgment reply. **Changes:** - Added imports for `abortEmbeddedPiRun`, `formatAbortReplyText`, `isAbortRequestText`, `stopSubagentsForRequester`, and `clearSessionQueues` - Inserted abort-check block before `enqueueFollowupRun` at line 237-252 to intercept abort requests during active runs - Used existing abort infrastructure (`abort.ts`) to detect and format abort messages **Behavior:** - Stop/abort messages sent while agent is generating now halt immediately instead of queuing - Users receive acknowledgment reply with subagent count if applicable - Normal (non-abort) messages continue to enqueue as before <h3>Confidence Score: 5/5</h3> - Safe to merge - focused bug fix with well-tested abort infrastructure - The change is a clean, minimal fix that intercepts abort messages before they're enqueued. It reuses existing, well-tested abort functions (`isAbortRequestText`, `abortEmbeddedPiRun`, `clearSessionQueues`, `stopSubagentsForRequester`) and only modifies the enqueue decision point. The logic is properly guarded (runs only when `isActive && (shouldFollowup || resolvedQueue.mode === "steer")`), and tests exist for the abort detection logic. No new functionality is introduced - just moving the abort check earlier in the flow. - No files require special attention _{Last reviewed commit: d58b946} <!-- greptile_other_comments_section --> _{(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!} <!-- /greptile_comment -->