hermes - 💡(How to fix) Fix Dashboard session deletion broken + CLI/gateway data source desync [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

{"title": "Dashboard session deletion broken + CLI/gateway data source desync", "body": "## Bug Description\n\nTwo related bugs:\n\n### Bug 1: Dashboard "Delete Session" button does nothing\n\nWhen selecting a session in the dashboard (desktop window) and clicking delete, the operation silently fails. No error message is shown to the user, and the session remains in the list.\n\nRoot cause: The frontend calls session.delete via WebSocket JSON-RPC to the gateway, but the gateway has no handler registered for this RPC method. The request is sent but never processed.\n\nEvidence:\n- curl -X DELETE http://localhost:8642/api/sessions/{id} returns 404: Not Found\n- Gateway route table (in gateway/platforms/api_server.py) only registers /v1/responses/{response_id} DELETE and /api/jobs/* DELETE — there is no session.delete or /api/sessions handler\n- The dashboard frontend (React) sends session.delete via WebSocket, but gateway never responds to it\n\n### Bug 2: CLI-deleted sessions still visible in dashboard\n\nRunning hermes sessions delete <id> removes the session from state.db (confirmed: session disappears from hermes sessions list), but the dashboard still shows the session.\n\nRoot cause: The CLI writes directly to state.db, while the gateway maintains its own in-memory session list that is only populated at startup. There is no invalidation mechanism — gateway never re-reads state.db after startup.\n\n### Bug 3 (possibly related): One conversation split into multiple sessions\n\nA single logical conversation appears as 3 separate sessions in the dashboard. This is likely a symptom of the same underlying architecture issue — gateway session management is inconsistent.\n\n## Steps to Reproduce\n\n1. Have multiple sessions in hermes sessions list\n2. Open hermes dashboard in browser\n3. Select any session → click delete\n4. Session remains in dashboard list\n5. Run hermes sessions list — session is gone from CLI but still visible in dashboard\n\n## Expected Behavior\n\n- Dashboard delete button should actually delete the session\n- CLI and dashboard should reflect the same data source\n- Sessions should not be arbitrarily split\n\n## Environment\n\n- OS: Windows 10\n- Hermes Agent version: latest\n- Gateway: running as hermes gateway (aiohttp-based)\n- Dashboard: running as hermes dashboard (FastAPI/uvicorn, separate process)\n\n## Additional Context\n\n- Gateway stderr log shows only MCP connection warnings and 401 auth errors — no session-delete related errors (because the RPC method doesn't exist, so no error is raised)\n- Restarting gateway (hermes gateway restart) causes the dashboard to re-sync and show correct data, confirming the gateway caches session list at startup only\n- Architecture: Dashboard (FastAPI) ↔ WebSocket JSON-RPC ↔ Gateway (aiohttp) ↔ state.db. CLI writes directly to state.db bypassing gateway.\n", "labels": ["bug", "sessions", "dashboard", "gateway"]}

Root Cause

{"title": "Dashboard session deletion broken + CLI/gateway data source desync", "body": "## Bug Description\n\nTwo related bugs:\n\n### Bug 1: Dashboard "Delete Session" button does nothing\n\nWhen selecting a session in the dashboard (desktop window) and clicking delete, the operation silently fails. No error message is shown to the user, and the session remains in the list.\n\nRoot cause: The frontend calls session.delete via WebSocket JSON-RPC to the gateway, but the gateway has no handler registered for this RPC method. The request is sent but never processed.\n\nEvidence:\n- curl -X DELETE http://localhost:8642/api/sessions/{id} returns 404: Not Found\n- Gateway route table (in gateway/platforms/api_server.py) only registers /v1/responses/{response_id} DELETE and /api/jobs/* DELETE — there is no session.delete or /api/sessions handler\n- The dashboard frontend (React) sends session.delete via WebSocket, but gateway never responds to it\n\n### Bug 2: CLI-deleted sessions still visible in dashboard\n\nRunning hermes sessions delete <id> removes the session from state.db (confirmed: session disappears from hermes sessions list), but the dashboard still shows the session.\n\nRoot cause: The CLI writes directly to state.db, while the gateway maintains its own in-memory session list that is only populated at startup. There is no invalidation mechanism — gateway never re-reads state.db after startup.\n\n### Bug 3 (possibly related): One conversation split into multiple sessions\n\nA single logical conversation appears as 3 separate sessions in the dashboard. This is likely a symptom of the same underlying architecture issue — gateway session management is inconsistent.\n\n## Steps to Reproduce\n\n1. Have multiple sessions in hermes sessions list\n2. Open hermes dashboard in browser\n3. Select any session → click delete\n4. Session remains in dashboard list\n5. Run hermes sessions list — session is gone from CLI but still visible in dashboard\n\n## Expected Behavior\n\n- Dashboard delete button should actually delete the session\n- CLI and dashboard should reflect the same data source\n- Sessions should not be arbitrarily split\n\n## Environment\n\n- OS: Windows 10\n- Hermes Agent version: latest\n- Gateway: running as hermes gateway (aiohttp-based)\n- Dashboard: running as hermes dashboard (FastAPI/uvicorn, separate process)\n\n## Additional Context\n\n- Gateway stderr log shows only MCP connection warnings and 401 auth errors — no session-delete related errors (because the RPC method doesn't exist, so no error is raised)\n- Restarting gateway (hermes gateway restart) causes the dashboard to re-sync and show correct data, confirming the gateway caches session list at startup only\n- Architecture: Dashboard (FastAPI) ↔ WebSocket JSON-RPC ↔ Gateway (aiohttp) ↔ state.db. CLI writes directly to state.db bypassing gateway.\n", "labels": ["bug", "sessions", "dashboard", "gateway"]}

Fix Action

Fixed

RAW_BUFFERClick to expand / collapse

{"title": "Dashboard session deletion broken + CLI/gateway data source desync", "body": "## Bug Description\n\nTwo related bugs:\n\n### Bug 1: Dashboard "Delete Session" button does nothing\n\nWhen selecting a session in the dashboard (desktop window) and clicking delete, the operation silently fails. No error message is shown to the user, and the session remains in the list.\n\nRoot cause: The frontend calls session.delete via WebSocket JSON-RPC to the gateway, but the gateway has no handler registered for this RPC method. The request is sent but never processed.\n\nEvidence:\n- curl -X DELETE http://localhost:8642/api/sessions/{id} returns 404: Not Found\n- Gateway route table (in gateway/platforms/api_server.py) only registers /v1/responses/{response_id} DELETE and /api/jobs/* DELETE — there is no session.delete or /api/sessions handler\n- The dashboard frontend (React) sends session.delete via WebSocket, but gateway never responds to it\n\n### Bug 2: CLI-deleted sessions still visible in dashboard\n\nRunning hermes sessions delete <id> removes the session from state.db (confirmed: session disappears from hermes sessions list), but the dashboard still shows the session.\n\nRoot cause: The CLI writes directly to state.db, while the gateway maintains its own in-memory session list that is only populated at startup. There is no invalidation mechanism — gateway never re-reads state.db after startup.\n\n### Bug 3 (possibly related): One conversation split into multiple sessions\n\nA single logical conversation appears as 3 separate sessions in the dashboard. This is likely a symptom of the same underlying architecture issue — gateway session management is inconsistent.\n\n## Steps to Reproduce\n\n1. Have multiple sessions in hermes sessions list\n2. Open hermes dashboard in browser\n3. Select any session → click delete\n4. Session remains in dashboard list\n5. Run hermes sessions list — session is gone from CLI but still visible in dashboard\n\n## Expected Behavior\n\n- Dashboard delete button should actually delete the session\n- CLI and dashboard should reflect the same data source\n- Sessions should not be arbitrarily split\n\n## Environment\n\n- OS: Windows 10\n- Hermes Agent version: latest\n- Gateway: running as hermes gateway (aiohttp-based)\n- Dashboard: running as hermes dashboard (FastAPI/uvicorn, separate process)\n\n## Additional Context\n\n- Gateway stderr log shows only MCP connection warnings and 401 auth errors — no session-delete related errors (because the RPC method doesn't exist, so no error is raised)\n- Restarting gateway (hermes gateway restart) causes the dashboard to re-sync and show correct data, confirming the gateway caches session list at startup only\n- Architecture: Dashboard (FastAPI) ↔ WebSocket JSON-RPC ↔ Gateway (aiohttp) ↔ state.db. CLI writes directly to state.db bypassing gateway.\n", "labels": ["bug", "sessions", "dashboard", "gateway"]}

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING