Gateway auto-resume on a non-interactive platform (webhook) acknowledges restoration instead of completing the interrupted turn

[denysgaievskyi]

Gateway auto-resume on a non-interactive platform (webhook) acknowledges restoration instead of completing the interrupted turn

Version

Hermes v2026.7.1 (0.18.0). Code path present unchanged at least since 0.13.0's session-resume feature.

Summary

When the gateway is interrupted mid-turn (SIGTERM drain / restart) and marks a session resume_pending, the next boot re-runs the session via _schedule_resume_pending_sessions(), which synthesizes an empty-text internal MessageEvent. The resume [System note] then tells the model to "report to the user that the session was restored successfully and ask what they would like to do next" and to "skip any unfinished work from the conversation history."

That guidance is correct for an interactive platform (CLI/Telegram/Slack DM), where a human is waiting and can answer "what next?". It is wrong for a non-interactive platform such as webhook, where there is no responder: the resumed turn emits a short "session restored" acknowledgement that goes nowhere, and — because it is told to skip unfinished work — it abandons the interrupted task instead of finishing it.

Where

gateway/run.py, the _is_resume_pending branch (~L17517-17549 in v2026.7.1):

if message:
    _resume_guidance = "Address the user's NEW message below FIRST ..."
else:
    _resume_guidance = (
        "Report to the user that the session was restored "
        "successfully and ask what they would like to do next."
    )
message = (
    f"[System note: The previous turn was interrupted by {_reason_phrase}; "
    f"the gateway is now back online. Any restart/shutdown command in the "
    f"history has already run — do NOT re-execute or verify it. {_resume_guidance} "
    f"Do NOT re-execute old tool calls — skip any unfinished work from the "
    f"conversation history.]"
    + (f"\n\n{message}" if message else "")
)

Reproduce

1. Run the gateway with a webhook platform adapter connected.
2. Send a webhook event that kicks off a long-running agent task (multiple tool turns).
3. While it is mid-task, send SIGTERM (drain) so the session is marked resume_pending, then let the process exit and restart.
4. On boot, _schedule_resume_pending_sessions() re-runs the session.

Observed: the resumed turn is 1 API call producing a short "session restored" text response (finish_reason=stop, no tool calls); the interrupted task is not completed and no downstream output is produced.

Expected: on a non-interactive platform, the resumed turn should continue and complete the interrupted task (re-run the remaining tool work), not emit an interactive "restored" acknowledgement.

Suggested fix

Make the empty-message resume guidance platform-aware. For interactive platforms keep the current "report restored / ask what next" behaviour. For non-interactive platforms (webhook, and any adapter without a live responder), instruct the model to continue and complete the interrupted turn, and drop the "skip any unfinished work" clause for that case (keep the "a restart/shutdown command already ran, don't re-run it" caveat). Idempotency of the completed work is the integration's responsibility (dedup on the downstream write).

Impact

Session-resume marks + re-schedules correctly, but for webhook integrations the interrupted work is silently dropped on resume — the operator must re-trigger manually. This defeats the practical value of resume_pending for automated (non-interactive) gateway workloads.

Related

• Gateway restart can lose long-running sessions during shutdown drain #27856 (closed) — added the pre-drain resume_pending marker this builds on. That fix makes the session recoverable; this issue is the next layer: the recovered non-interactive session doesn't complete the interrupted work.
• Feature request: resume interrupted tasks on restart #9673 (open) — broader "resume interrupted tasks on restart" feature request. This issue is narrower and concrete: the existing _resume_guidance empty-message branch is interactive-only, so non-interactive (webhook) resumes acknowledge restoration and skip the work.

Environment note

Observed on a webhook-only gateway deployment (single-pod, EKS). Session marking + boot re-scheduling work correctly (fresh Scheduled auto-resume for N session(s) on boot); only the resumed turn's behaviour is wrong for the non-interactive case.

[Ahmett101]

I'm working on this. Branch will be at: https://github.com/Ahmett101/hermes-agent/tree/fix/57056-resume-guidance-non-interactive

[Ahmett101]

PR submitted: #57323

[GottZ]

This was generated by AI during triage.

Summary

One PR, #57323, addresses issue #57056 by making the primary resume-note construction platform-aware so non-interactive gateway sessions continue interrupted work instead of requesting unavailable user input. Its diff does not cover the separate empty-turn safety-net path, where the reported abandonment behavior remains reachable.

Related pull requests

• fix(gateway): finish interrupted turn on non-interactive platform resume #57323 best fix — (+173/-10) — partial fix and best existing fix: fix(gateway): finish interrupted turn on non-interactive platform resume #57323 changes the primary resume-pending branch for webhook, api_server, and msgraph_webhook, preserving interactive behavior while directing non-interactive sessions to complete interrupted work. Consistent with the keep_open review on fix(gateway): finish interrupted turn on non-interactive platform resume #57323, the diff misses the second note-construction path at gateway/run.py:19106-19131, and its tests reproduce the selection logic locally rather than behaviorally exercising the production paths as required by AGENTS.md:1358-1379.

Suggested consolidation

Keep #57323 open with a salvage path as the best existing fix: route both resume-note construction sites through one platform-aware helper, then replace the source/layout-oriented or locally duplicated assertions with behavioral coverage for interactive and non-interactive notes through both the primary injection and empty-turn safety-net paths. This follows the visible keep_open review and addresses its blocking gaps; there are no duplicate PRs to close.

Complex graph

flowchart LR
    classDef open fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
    classDef merged fill:#dcfce7,stroke:#15803d,color:#14532d
    classDef closed fill:#e5e7eb,stroke:#6b7280,color:#1f2937
    classDef unverified fill:#f3f4f6,stroke:#9ca3af,color:#374151
    classDef best stroke-width:3px,stroke:#b45309
    classDef target stroke-width:3px,stroke:#4338ca
    I57056(["issue #57056 (open)"])
    P57323["PR #57323 (open)"]
    P57323 -->|best fix| I57056
    class I57056 open
    class I57056 target
    class P57323 open
    class P57323 best
    click I57056 "https://github.com/NousResearch/hermes-agent/issues/57056"
    click P57323 "https://github.com/NousResearch/hermes-agent/pull/57323"

Loading

Graph: solid arrow = fixes / best fix, dashed arrow = partial or unverified (see edge label); boxed group = PRs duplicating each other; amber border = best fix; indigo border = target; gray node = closed (state tag in the node label).

Cross-PR triage: Reviewed 1 pull request and 1 issue in this complex. Each diff was read against this issue; Assessment working set: 11 kB of PR diffs, 9 kB of issue/PR text, 1 kB of discussion (3 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.