mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-06-09 08:21:50 +00:00
c54b935873
The desktop `/title <name>` command 404s with "Session not found" on every platform (reported on Windows in #38508). Root cause: `session.create` returns two distinct ids — a *runtime* session id (held in `activeSessionIdRef`) and a `stored_session_id` (the DB `sessions.id`) — and deliberately does NOT persist a DB row until the first turn. Routing `/title` through the REST `PATCH /api/sessions/{id}` endpoint (as #38576 proposed) resolves the id against the `sessions` table, so the runtime id — or any brand-new, not-yet-persisted session — never resolves and returns 404. This is an id-type mismatch, not a Windows file-locking quirk, so it fails on macOS and Linux too. Fix: route `/title <name>` through the gateway's `session.title` RPC — the exact path the TUI already uses (`ui-tui/.../slash/commands/core.ts`). The RPC maps the runtime id to the in-memory session, writes through the gateway's own DB connection, and queues the title (`pending: true`) when the row isn't persisted yet, so it works for a fresh chat. The sidebar is then refreshed via the existing `refreshSessions()` plumbing. Keeps the sidebar-refresh wiring and `refreshSessions` threading from #38576; replaces only the broken REST/slash-worker write path. A bare `/title` (no arg) still falls through to the worker to show the current title. Tests rewritten to assert `session.title` routing with the runtime-vs- stored id distinction (which the original mock collapsed), plus the queued/`pending` fresh-chat case and the error path. Supersedes #38576. Fixes #38508. Co-authored-by: xxxigm <54813621+xxxigm@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| bootstrap-installer | ||
| desktop | ||
| shared | ||