mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-04-25 00:51:20 +00:00
f24956ba12
When context compression fires mid-session, run_agent's _compress_context ends the current session, creates a new child session linked by parent_session_id, and resets the SQLite flush cursor. New messages land in the child; the parent row ends up with message_count = 0. A user who runs 'hermes --resume <original_id>' sees a blank chat even though the transcript exists — just under a descendant id. PR #12920 already fixed the exit banner to print the live descendant id at session end, but that didn't help users who resume by a session id captured BEFORE the banner update (scripts, sessions list, old terminal scrollback) or who type the parent id manually. Fix: add SessionDB.resolve_resume_session_id() which walks the parent→child chain forward and returns the first descendant with at least one message row. Wire it into all three resume entry points: - HermesCLI._preload_resumed_session() (early resume at run() time) - HermesCLI._init_agent() (the classical resume path) - /resume slash command Semantics preserved when the chain has no descendants with messages, when the requested session already has messages, or when the id is unknown. A depth cap of 32 guards against malformed loops. This does NOT concatenate the pre-compression parent transcript into the child — the whole point of compression is to shrink that, so replaying it would blow the cache budget we saved. We just jump to the post-compression child. The summary already reflects what was compressed away. Tests: tests/hermes_state/test_resolve_resume_session_id.py covers - the exact 6-session shape from the issue - passthrough when session has messages / no descendants - passthrough for nonexistent / empty / None input - middle-of-chain redirects - fork resolution (prefers most-recent child) Closes #15000 |
||
|---|---|---|
| .. | ||
| test_resolve_resume_session_id.py | ||