[Bug]: Gateway Exits Unexpectedly on Long Prompts / Context

[f41007]

Bug Description

The Hermes Agent UI crash/terminates the gateway connection whenever a long prompt or command is submitted. The UI terminal outputs ⁠gateway exited⁠ and the process stops working.

Environment:
Application: Hermes Agent (UI Version)
OS: running on ubuntu, stream on windows 7 and macbook monetery

Steps to Reproduce

1. Open the Hermes Agent UI.
2. Input a long, detailed prompt or a long sequence of code/commands into the chat/command box.
3. Submit the prompt.
4. Observe the terminal output after a few moments of processing.

Expected Behavior

The gateway should handle longer context lengths or return a proper timeout/token-limit warning instead of exiting the process.

Actual Behavior

The gateway process crashes immediately and prints the following error to the terminal:

• gateway exited | opc | 172.4k/256k

$ gateway exited

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

Ok

Operating System

Ubuntu 24.04

Python Version

No response

Hermes Version

0.18.2

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[GottZ]

This was generated by AI during triage.

Summary

One PR references issue #66286. PR #66323 adds an exception boundary around gateway dispatch so handler failures return a JSON-RPC error instead of terminating the stdio loop, but the evidence does not establish that such an exception caused the reported long-prompt/context exits.

Related pull requests

• fix(gateway): catch dispatch exceptions so the gateway survives handler crashes (#66286) #66323 best fix — (+23/-1) — partial fix: Wraps dispatch(req) failures with stderr/crash-log reporting and a JSON-RPC error response, allowing the gateway loop to continue. The contributor keep_open review on fix(gateway): catch dispatch exceptions so the gateway survives handler crashes (#66286) #66323 supports the approach but requires a regression test proving an inline dispatch exception preserves the request ID and permits a subsequent request; the current diff contains no such test and does not demonstrate the reported long-prompt causal path.

Suggested consolidation

Merge #66323 after adding the requested entry-loop regression test; it is the best available focused resilience fix, while remaining only a partial fix until the long-prompt failure mechanism is reproduced or otherwise linked to an escaping dispatch exception. 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
    I66286(["issue #66286 (open)"])
    P66323["PR #66323 (open)"]
    P66323 -->|best fix| I66286
    class I66286 open
    class I66286 target
    class P66323 open
    class P66323 best
    click I66286 "https://github.com/NousResearch/hermes-agent/issues/66286"
    click P66323 "https://github.com/NousResearch/hermes-agent/pull/66323"

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: 1 kB of PR diffs, 3 kB of issue/PR text, 1 kB of discussion (2 comments), 2 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.