hermes - 💡(How to fix) Fix Feature idea: Preserve-on-failure principle for context compression subsystems [1 participants]

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…
GitHub stats
NousResearch/hermes-agent#11588Fetched 2026-04-18 06:00:07
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Participants

Error Message

When context compression fails (LLM unavailable, summary generation error, network timeout, etc.), the system currently loses conversation history — the middle turns are deleted and replaced with an error marker. This is a destructive failure mode. 2. _generate_summary() returning empty/fallback string: Keep original middle messages as-is, do not replace them with a static error message.

Root Cause

  • Long conversations are high-value: The more messages in a session, the more valuable the context, and the more painful its loss.
  • Failure is often transient: Network blips or API rate limits cause brief failures that could succeed on retry — but the current code commits data loss immediately.
  • User trust: Users who notice missing context assume the system is broken, even if only compression failed.

Code Example

# In compress():
summary = self._generate_summary(turns_to_summarize, focus_topic=focus_topic)

# PRESERVE-ON-FAILURE: explicit None from _generate_summary
if summary is None:
    logger.warning("Compression unavailable — preserving all %d original messages", n_messages)
    return messages  # <— nothing deleted

if not summary:  # fallback was generated
    logger.warning("Summary empty — preserving original middle %d messages", compress_end - compress_start)
    for i in range(compress_start, compress_end):
        compressed.append(messages[i].copy())
    # ... tail + sanitization
    return compressed
RAW_BUFFERClick to expand / collapse

Feature Idea: Preserve-on-Failure Principle for Context Compression

Problem

When context compression fails (LLM unavailable, summary generation error, network timeout, etc.), the system currently loses conversation history — the middle turns are deleted and replaced with an error marker. This is a destructive failure mode.

Proposed Principle: Preserve-on-Failure

Any compression subsystem should implement "preserve-on-failure": when compression cannot complete, keep the original data intact rather than deleting it. The contract is:

"Compression is an optimization. If the optimization fails, the original remains unchanged."

Concrete Changes Needed

  1. _generate_summary() returning None: Return all original messages unchanged immediately — do not delete anything.

  2. _generate_summary() returning empty/fallback string: Keep original middle messages as-is, do not replace them with a static error message.

  3. Context Engine plugin ABC (agent/context_engine.py): The compress() signature should document that it either returns a compressed list OR the original list if compression fails — callers must handle both cases.

  4. Compression counter: Increment compression_count even on failure (for observability), but log clearly that it was a failure.

  5. User notification: The warning message should clearly state "all X original messages preserved" so operators know the safety net worked.

Why This Matters

  • Long conversations are high-value: The more messages in a session, the more valuable the context, and the more painful its loss.
  • Failure is often transient: Network blips or API rate limits cause brief failures that could succeed on retry — but the current code commits data loss immediately.
  • User trust: Users who notice missing context assume the system is broken, even if only compression failed.

Implementation Sketch

# In compress():
summary = self._generate_summary(turns_to_summarize, focus_topic=focus_topic)

# PRESERVE-ON-FAILURE: explicit None from _generate_summary
if summary is None:
    logger.warning("Compression unavailable — preserving all %d original messages", n_messages)
    return messages  # <— nothing deleted

if not summary:  # fallback was generated
    logger.warning("Summary empty — preserving original middle %d messages", compress_end - compress_start)
    for i in range(compress_start, compress_end):
        compressed.append(messages[i].copy())
    # ... tail + sanitization
    return compressed

Labels

enhancement, context-engine, reliability, user-experience

extent analysis

TL;DR

Implement the "Preserve-on-Failure" principle in the context compression subsystem to prevent data loss when compression fails.

Guidance

  • Review the _generate_summary() function to ensure it returns None when compression fails, and modify the compress() function to handle this case by preserving the original data.
  • Update the compress() function signature in the Context Engine plugin to document that it may return either the compressed list or the original list if compression fails.
  • Modify the compression counter to increment on failure and log a clear failure message for observability.
  • Enhance user notification to clearly state that original messages are preserved in case of compression failure.

Example

if summary is None:
    logger.warning("Compression unavailable — preserving all %d original messages", n_messages)
    return messages  # preserve original data

Notes

The proposed changes aim to improve the reliability and user experience of the context compression subsystem. However, the implementation details may vary depending on the specific requirements and constraints of the system.

Recommendation

Apply the workaround by implementing the "Preserve-on-Failure" principle in the context compression subsystem, as it provides a clear and effective solution to prevent data loss and improve user trust.

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