hermes - 💡(How to fix) Fix User message arriving during preflight compaction aborts the agent loop when an alt context engine is active

Summary

When an alternative context engine (e.g. hermes-mneme, hermes-lcm) handles preflight compaction on every turn, a user message sent while compaction is in progress prints "new message detected, interrupting..." but the agent loop then terminates instead of resuming with the new message merged in.

Expected

Same behavior as the default compressor: compaction completes (or is cooperatively interrupted), the new user message is appended to the buffer, and the LLM call proceeds with the combined context.

Actual

• "new message detected, interrupting..." is printed.
• The in-flight preflight compress() call continues running synchronously (the host has no cancellation surface for alt-engine compress()).
• After compress() returns, the agent loop has already been torn down by the interrupt path. The new message is not delivered to the LLM.
• The turn is effectively lost: no assistant response, no error surfaced to the user.

Repro

1. Configure Hermes with a context-engine plugin whose should_compress() / should_compress_preflight() returns True on every turn (i.e., the plugin replaces the default compressor and assembles context itself).
2. Trigger any turn that performs non-trivial work inside the plugin's compress() (embedding HTTP, retrieval, LLM enrichment, etc.).
3. While preflight compaction is running, type a new user message and submit.
4. Observe "new message detected, interrupting..." followed by nothing.

Affected versions

Reproducible on current Hermes (#20424 — "call should_compress_preflight() for sub-threshold engines" — landed; this PR is what causes preflight compress() to run on every turn for alt engines, widening the window for this bug).

Suggested fix shape

The interrupt path is currently designed for the LLM-call phase. It needs to either:

1. Queue the new user message and resume the agent loop after preflight compress() returns (so compress() doesn't get cancelled mid-flight and the buffer is dirtied with the new message before the LLM call). OR
2. Provide a cancellation API for context engines — e.g. context_engine.cancel_preflight() — so engines can cooperatively abort, snapshot state, and signal that the host should re-call compress() with the updated buffer.

Either shape would resolve the lost-turn symptom. Option 1 is simpler and doesn't require any change to existing context engines.

Related

• #25115 — preflight status messaging for alt engines
• #20316 / #20424 — preflight call path for sub-threshold engines
• stephenschoettler/hermes-lcm#168 — same surface area, UX side