Issue Station
Sign In
Tools hereToolbox

hermes - 💡(How to fix) Fix [Bug]: WebUI manual compression times out behind Cloudflare/Caddy and may leave session state inconsistent [1 pull requests]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

  • The UI should not display raw HTML proxy error pages as the compression error message.

Additional Logs / Traceback (optional)

There is also a frontend error handling issue: non-JSON HTML responses from Cloudflare are surfaced directly as Compression failed: <html...>.

Root Cause

I searched existing issues and found several context compression reliability issues, but did not find one specifically about WebUI manual compression timing out behind Cloudflare/Caddy because it is implemented as a long synchronous HTTP request.

Fix Action

Fixed

Code Example

messages_before: 251
rough_tokens_before: ~276k
messages_summarized: 243
serialized_summary_input_rough_tokens: ~24k
summary_target_tokens: 12000

---

Browser
  -> Cloudflare orange-cloud proxy
  -> Caddy reverse proxy
  -> hermes-webui:8787

---

hermes-agent:
  image: nousresearch/hermes-agent:latest
  command: gateway run
  volumes:
    - hermes-home:/home/hermes/.hermes
    - hermes-agent-src:/opt/hermes

hermes-webui:
  image: ghcr.io/nesquena/hermes-webui:latest
  ports:
    - "127.0.0.1:<port>:8787"
  volumes:
    - hermes-home:/home/hermeswebui/.hermes
    - hermes-agent-src:/home/hermeswebui/.hermes/hermes-agent
    - ${HERMES_WORKSPACE:-~/workspace}:/workspace
  environment:
    - HERMES_WEBUI_HOST=0.0.0.0
    - HERMES_WEBUI_PORT=8787
    - HERMES_WEBUI_STATE_DIR=/home/hermeswebui/.hermes/webui

---

I cannot paste a full debug share publicly because the WebUI runtime config contains provider credentials. Relevant redacted evidence:

Cloudflare returned 524 while POST /api/session/compress was pending.

Backend log pattern:
2026-05-08 17:45:29 Auxiliary compression: using auto (...) at [REDACTED_BASE_URL]
2026-05-08 17:48:45 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe

---

2026-05-08 17:45:29,487 INFO agent.auxiliary_client: Auxiliary compression: using auto (gpt-5.5) at https://<api-site>/v1/
2026-05-08 17:48:45,335 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe

Earlier attempt:

2026-05-08 17:37:33,263 INFO agent.auxiliary_client: Auxiliary compression: using auto (gpt-5.5) at https://<api-site>/v1/
2026-05-08 17:40:22,812 WARNING root: Context compression: no provider available for summary. Middle turns will be dropped without summary for 600 seconds.
2026-05-08 17:40:22,947 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe
RAW_BUFFERClick to expand / collapse

Bug Description

When Hermes WebUI is deployed behind Caddy reverse proxy and Cloudflare orange-cloud proxy, triggering manual context compression can exceed the proxy request timeout.

The browser receives a Cloudflare 524 HTML page and WebUI displays it as:

Compression failed: <!DOCTYPE html> ... 524: A timeout occurred

Server logs show:

Manual session compression failed: [Errno 32] Broken pipe

In my case, the session appears to have been compressed and saved anyway, but the browser received the 524 response, so the UI reported failure. This creates a confusing and potentially inconsistent state: the user sees compression failed, while the session may already have been modified.

I searched existing issues and found several context compression reliability issues, but did not find one specifically about WebUI manual compression timing out behind Cloudflare/Caddy because it is implemented as a long synchronous HTTP request.

Steps to Reproduce

  1. Deploy Hermes WebUI behind Caddy.
  2. Put Cloudflare in front of the domain with orange-cloud proxy enabled.
  3. Open a long WebUI session with a large transcript.
  4. Trigger manual context compression from WebUI.
  5. Wait for compression to run longer than the proxy timeout.
  6. WebUI displays Compression failed: <!DOCTYPE html> ... 524: A timeout occurred.
  7. Server logs show Manual session compression failed: [Errno 32] Broken pipe.

Observed session size:

messages_before: 251
rough_tokens_before: ~276k
messages_summarized: 243
serialized_summary_input_rough_tokens: ~24k
summary_target_tokens: 12000

Deployment topology:

Browser
  -> Cloudflare orange-cloud proxy
  -> Caddy reverse proxy
  -> hermes-webui:8787

Relevant Compose details:

hermes-agent:
  image: nousresearch/hermes-agent:latest
  command: gateway run
  volumes:
    - hermes-home:/home/hermes/.hermes
    - hermes-agent-src:/opt/hermes

hermes-webui:
  image: ghcr.io/nesquena/hermes-webui:latest
  ports:
    - "127.0.0.1:<port>:8787"
  volumes:
    - hermes-home:/home/hermeswebui/.hermes
    - hermes-agent-src:/home/hermeswebui/.hermes/hermes-agent
    - ${HERMES_WORKSPACE:-~/workspace}:/workspace
  environment:
    - HERMES_WEBUI_HOST=0.0.0.0
    - HERMES_WEBUI_PORT=8787
    - HERMES_WEBUI_STATE_DIR=/home/hermeswebui/.hermes/webui

Expected Behavior

Manual WebUI compression should not depend on a single long-lived HTTP request.

Expected behavior:

  • WebUI submits a background compression job and receives a job id quickly.
  • WebUI polls job status or receives progress updates.
  • When the job finishes, WebUI refreshes the session state.
  • If the browser disconnects or Cloudflare/Caddy times out, the backend should still expose the final job/session state clearly.
  • The UI should not display raw HTML proxy error pages as the compression error message.

Actual Behavior

POST /api/session/compress blocks until the compression LLM call completes.

When compression takes too long, Cloudflare returns 524 to the browser. The frontend then displays the raw Cloudflare HTML response as a compression failure.

The backend later logs Broken pipe, because it tries to write the response after the client/proxy connection has already closed.

The session may already have been compressed and saved, even though the UI reports failure.

Affected Component

Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

N/A (CLI only)

Debug Report

I cannot paste a full debug share publicly because the WebUI runtime config contains provider credentials. Relevant redacted evidence:

Cloudflare returned 524 while POST /api/session/compress was pending.

Backend log pattern:
2026-05-08 17:45:29 Auxiliary compression: using auto (...) at [REDACTED_BASE_URL]
2026-05-08 17:48:45 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe

Operating System

AlmaLinux 9.7

Python Version

3.12.13

Hermes Version

v0.13.0

Additional Logs / Traceback (optional)

2026-05-08 17:45:29,487 INFO agent.auxiliary_client: Auxiliary compression: using auto (gpt-5.5) at https://<api-site>/v1/
2026-05-08 17:48:45,335 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe

Earlier attempt:

2026-05-08 17:37:33,263 INFO agent.auxiliary_client: Auxiliary compression: using auto (gpt-5.5) at https://<api-site>/v1/
2026-05-08 17:40:22,812 WARNING root: Context compression: no provider available for summary. Middle turns will be dropped without summary for 600 seconds.
2026-05-08 17:40:22,947 WARNING api.routes: Manual session compression failed: [Errno 32] Broken pipe

Root Cause Analysis (optional)

The WebUI manual compression endpoint appears to run compression synchronously inside the HTTP request.

Observed local code path:

  • Frontend calls api('/api/session/compress', { method: 'POST', ... }).
  • API route constructs an AIAgent.
  • The handler calls agent.context_compressor.compress(...) synchronously.
  • The handler only returns after the compression LLM call completes and the session is saved.

For large transcripts, the compression summary request can exceed Cloudflare/Caddy request timeouts. Cloudflare returns 524 to the browser, while the backend may continue running and later hit Broken pipe when it tries to write to the closed connection.

There is also a frontend error handling issue: non-JSON HTML responses from Cloudflare are surfaced directly as Compression failed: <html...>.

Proposed Fix (optional)

Convert WebUI manual compression into an asynchronous job.

Suggested behavior:

  1. POST /api/session/compress enqueues a compression job and returns quickly with { job_id }.
  2. Add a polling endpoint such as GET /api/session/compress/status?job_id=....
  3. Persist job state: queued / running / saving / done / failed.
  4. When done, return the updated session state or session id so WebUI can refresh.
  5. If the client disconnects or a reverse proxy times out, the backend job should still have a queryable final state.
  6. Frontend should detect HTML/non-JSON proxy errors and show a concise message instead of rendering the full Cloudflare page.
  7. Backend logs should distinguish real compression failure from client disconnect / broken pipe after successful save.

Are you willing to submit a PR for this?

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

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#vector store#embedding generation#cache error#request timeout

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: WebUI manual compression times out behind Cloudflare/Caddy and may leave session state inconsistent [1 pull requests]