Summary
turn.start returns injectedContext: "" for a query whose top retrieval hits are dominated by near-duplicate question traces from previous sessions — even though memory.search for the same query returns strong hits including the answer-bearing trace. Net effect: the more often a user asks the same question, the deafer the memory becomes for exactly that question.
Environment
- main @ b60616d, compiled
dist/bridge.cjs (real core + SQLite), Hermes adapter
- embedding: local; reproduced with
llm.provider: host and with no usable LLM (A/B tested — LLM availability is not the variable)
Reproduction (verified on a live install)
- Session 1:
Remember this fact: HERMES_REAL_E2E_1910 means the bridge leak fix verification. → trace persisted ✓
- Session 2 (immediately after): ask
What does HERMES_REAL_E2E_1910 mean? → recall works (clean store: the fact is the only hit)
- Ask the same question in 3 more separate sessions (each one stores its own question-trace)
- Now drive
turn.start directly over JSON-RPC with the same question:
memory.search → 4 hits (tier 2), including the answer-bearing trace
turn.start → injectedContext: "" (0 chars)
Control test at the same moment, same config, against the same store: a clean marker (HERMES_HOST_LLM_0612, stored once, never re-asked) → turn.start injects 826 chars. So the collapse is driven purely by the near-duplicate question traces crowding the hit set — the injection filter drops them (reasonably, they're self-similar to the live query) but the answer-bearing trace is lost with them, and nothing is injected at all.
Why it matters
Repeated questions are precisely the signal that a memory matters to the user, yet that repetition poisons future recall for it. The failure is silent: capture keeps succeeding, memory.search keeps hitting, the user just stops getting injections and has no error to act on.
Suggested directions
- After de-duplicating near-identical question traces from the candidate set, re-fill the injection budget from remaining hits (the answer trace was ranked right behind them) instead of returning empty
- Consider down-weighting pure-question traces (no informative assistant text) at injection time, or merging Q-repeat traces with their answered ancestor
- Emit a debug-level reason when injection collapses to empty despite non-empty retrieval (
filteredAll=true) so this is diagnosable in the viewer
Found while validating #1910 / PR #1911 on a real hermes-agent v0.16.0 host; unrelated to the process-leak fix (reproduces on unpatched core paths — the injection pipeline is untouched by that PR).
Summary
turn.startreturnsinjectedContext: ""for a query whose top retrieval hits are dominated by near-duplicate question traces from previous sessions — even thoughmemory.searchfor the same query returns strong hits including the answer-bearing trace. Net effect: the more often a user asks the same question, the deafer the memory becomes for exactly that question.Environment
dist/bridge.cjs(real core + SQLite), Hermes adapterllm.provider: hostand with no usable LLM (A/B tested — LLM availability is not the variable)Reproduction (verified on a live install)
Remember this fact: HERMES_REAL_E2E_1910 means the bridge leak fix verification.→ trace persisted ✓What does HERMES_REAL_E2E_1910 mean?→ recall works (clean store: the fact is the only hit)turn.startdirectly over JSON-RPC with the same question:Control test at the same moment, same config, against the same store: a clean marker (
HERMES_HOST_LLM_0612, stored once, never re-asked) →turn.startinjects 826 chars. So the collapse is driven purely by the near-duplicate question traces crowding the hit set — the injection filter drops them (reasonably, they're self-similar to the live query) but the answer-bearing trace is lost with them, and nothing is injected at all.Why it matters
Repeated questions are precisely the signal that a memory matters to the user, yet that repetition poisons future recall for it. The failure is silent: capture keeps succeeding,
memory.searchkeeps hitting, the user just stops getting injections and has no error to act on.Suggested directions
filteredAll=true) so this is diagnosable in the viewerFound while validating #1910 / PR #1911 on a real hermes-agent v0.16.0 host; unrelated to the process-leak fix (reproduces on unpatched core paths — the injection pipeline is untouched by that PR).