Hermes adapter: prefetch can exceed host 8s budget in default shared-bridge mode

[wyjuven]

Summary

In @memtensor/memos-local-plugin 2.0.12, the Hermes adapter uses a process-scoped shared stdio bridge by default:

mode = os.environ.get("MEMOS_HERMES_BRIDGE_MODE", "shared")

Under normal multi-session gateway traffic, the Hermes host can report:

Memory provider 'memtensor' prefetch timed out after 8.0s; skipping it until the stuck call returns

The bridge/viewer can remain healthy when this occurs, so core.health or viewer availability alone does not identify the slow stage.

Environment

• @memtensor/memos-local-plugin: 2.0.12
• Hermes integration via adapters/hermes
• Multiple provider/session instances in one gateway process
• Default shared bridge mode

Expected behavior

A slow retrieval/capture request should be diagnosable, and automatic prefetch should not silently degrade without identifying the blocking phase.

Observed behavior

• Hermes gives up at its outer 8-second prefetch budget.
• The MemOS bridge can still appear connected and the viewer remains available.
• The adapter has long-RPC timeouts, but it does not expose enough per-phase timing/status to distinguish:
  • turn.start retrieval,
  • embedding or model work,
  • host reverse RPC,
  • stdio transport,
  • or interaction between concurrent shared-bridge leases.

Request

Could the Hermes adapter provide per-request timing/status for turn.start and shared-runtime in-flight/queue diagnostics?

A regression test would also help: simulate one slow request while another provider lease performs prefetch, then verify the second lease either completes within budget or receives a specific bounded/degraded result rather than an opaque host-side timeout.

Temporary workaround

Use MEMOS_HERMES_BRIDGE_MODE=legacy / the pre-shared-bridge adapter path while investigating, at the cost of losing the shared-bridge process-leak mitigation.