fix(memory): synchronous OpenViking prefetch with current turn's query

[per1970]

Problem

The OpenViking memory provider's prefetch() method ignores its query parameter entirely.
It returns background-thread results from queue_prefetch() which fired at the end of
the previous turn — meaning automatic memory context is always about the wrong topic.

Turn N (user asks about AWS):
  Agent responds → background thread searches OV for "AWS" → stores in cache

Turn N+1 (user asks about CSS):
  Agent starts → pulls cache → injects results about "AWS"
  The query "CSS" is literally ignored

First turn of every session gets zero context. Every subsequent turn gets stale context
from the previous topic. The model can manually call viking_search to compensate,
but the automatic recall that fires on every turn is working against it.

This was identified and analyzed in detail by @hammerhoundai in
volcengine/OpenViking#2253,
which documents the full comparison against Claude Code's synchronous recall approach.

Evidence from source

The prefetch() method in plugins/memory/openviking/__init__.py:

def prefetch(self, query: str, ...) -> str:
    # The query parameter? Completely ignored.
    # Just returns whatever the background thread found.
    with self._prefetch_lock:
        result = self._prefetch_result
    return f"## OpenViking Context\n{result}"

queue_prefetch() fires at end of turn N with query "AWS", stores in _prefetch_result.
prefetch() at start of turn N+1 with query "CSS" returns the "AWS" result. The API
signature takes a query parameter but the OpenViking provider throws it away.

Fix

prefetch() now does a synchronous POST /api/v1/search/find with the current
turn's query parameter — matching how Claude Code's plugin works. The stale
background-thread cache is drained (discarded).

Three changes:

1. Uses the actual query — prefetch(query="CSS") searches for "CSS", not "AWS"
2. Score threshold — minimum 0.35 (matches Claude Code's plugin), filters noise
3. Clean early return — returns "" when no client configured

queue_prefetch() is unchanged — it still fires background searches at end of turn
for pre-warming, but prefetch() no longer consumes those results.

How to test

1. Start Hermes with OpenViking memory provider configured
2. Turn 1: ask a question about topic A — note that first turn gets no context (expected)
3. Turn 2: ask about topic B — verify ## OpenViking Context contains results about B, not A
4. Turn 3: ask about topic C — verify context follows C, not B

Tested on

• WSL2 (Ubuntu 26.04), Hermes v0.14.0, OpenViking v0.3.21
• Python 3.11.15, httpx
• Verified: syntax check passes, plugin loads without errors

Related

• volcengine/OpenViking#2253 — root cause analysis and comparison with Claude Code
• Hermes issue fix(memory): prefetch cache lost on every gateway turn due to AIAgent recreation #9973 — related (prefetch cache lost on gateway AIAgent recreation) but different problem. This fix addresses relevance, not availability.

[per1970]

Non-coder disclaimer: I am not a coder. This fix was generated by Muninn (my Hermes AI agent) based on the documented analysis at volcengine/OpenViking#2253. I reviewed the change, applied the patch, tested it on a clean clone, and verified the fix works before filing. Happy to make any changes maintainers request.

[alt-glitch]

Related: #32444 (open, broader OpenViking reliability PR) also adds current-query fallback for recall/prefetch. Also related to #5838 (sync_recall feature) and closed #8474 (earlier attempt at same fix).

[wgd753]

Re-tested the top_k vs limit field on OV /api/v1/search/find endpoint:

top_k=1  → 10 results (R:8 M:2)
top_k=2  → 10 results (R:8 M:2)  
top_k=5  → 10 results (R:8 M:2)
top_k=20 → 10 results (R:8 M:2)

limit=2  → 2 results  ✅
limit=5  → 5 results  ✅

top_k has zero effect on this endpoint — always returns all results regardless of the value. limit correctly caps.

Suggestion: switch from top_k to limit to avoid uncontrolled context bloat.

[kshitijk4poor]

Merged via #51898. Your synchronous-prefetch diagnosis was the original root-cause identification for the stale-context problem, and your fix direction (use the current query in prefetch()) is exactly what shipped. Thanks for the detailed analysis.