Accidental issue — superseded by PR #2292

[kiwipaulrob]

Description

When the Hermes gateway runs multiple concurrent sessions (email threads, cron jobs, subagents) in one process, each session gets its own MemTensorProvider instance. Every MemosBridgeClient() construction closes whatever client holds the per-process (agent, no_viewer, runtime_home) singleton slot in _ACTIVE_CLIENTS — which belongs to a different session's provider.

Root cause

The module-level singleton tracker _ACTIVE_CLIENTS in bridge_client.py was keyed by (agent, no_viewer, runtime_home) — one slot per process. This was correct as a guard against issue #1910 (bridge process leak where one provider kept spawning new bridges per turn), but fatal when N provider instances coexist in one gateway process.

Evidence chain:

• Gateway process hosts 2+ bridge.mjs --no-viewer children, replacing one every 2-3s (PIDs churn constantly)
• Dashboard (single session, one provider) has one stable bridge, zero churn
• The only difference: provider-instance count
• Daemon (bridge.cjs --daemon, systemd, :18800) stable throughout

Fix

Widen the singleton key to (agent, no_viewer, runtime_home, owner_id) so concurrent provider instances in one process coexist instead of fighting.

Changes:

• bridge_client.py: key type widened tuple[str, bool, str] -> tuple[str, bool, str, str]; owner_id: str | None parameter added to __init__; _singleton_owner field set from owner_id or f\"anon-{id(self)}\"; key construction in both _register_active and _unregister_active updated
• init.py: both construction sites (initialize() and _reconnect_bridge()) in both shared-bridge and legacy modes pass owner_id=f\"provider-{id(self)}\"

Expected steady state after fix: daemon + 1 bridge per host process = 3 total; reconnect counts -> ~0.

Alternatives

• HTTP transport (Feature request: native HTTP transport for MemosBridgeClient (remote bridge) #1985) — the architectural end-state, but needs more design
• Process-wide shared ref-counted client — one JSON-RPC per process, sessions multiplexed

Type of change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

• Unit Test — the local test script verifies: distinct provider instances coexist in the tracker, same-owner replacement works, and unregister only removes self
• Living on production (kiwipaulrob's homelab) since 12 Aug 2026 — zero bridge client is closed storms since deployment (was thousands/day)

Checklist

• I have performed a self-review of my own code
• I have commented my code in hard-to-understand areas
• I have linked the issue to this PR (if applicable) — related: Bridge process leak: every turn spawns new bridge.cjs, 4+ processes accumulated #1910, fix: initialize() spawns new headless bridge without closing old one — process leak #1927, Feature request: native HTTP transport for MemosBridgeClient (remote bridge) #1985

[Memtensor-AI]

🤖 AutoDev has picked up this issue and started working on it.

Task ID: 5daf587c668e1502
Working branch: bugfix/autodev-2291-20260827191701124
Target branch: latest dev* branch
Workflow: opsp (analysis → coding → testing → PR)

I will post the PR link here once done. If I need more information, I will ask in the comments.

[kiwipaulrob]

Superseded by PR #2292 — this was opened via the wrong API endpoint (issue instead of PR).

[Memtensor-AI]

✅ AutoDev task 5daf587c668e1502 completed.

Summary: Fixes #2291. Widens the module-level _ACTIVE_CLIENTS key in apps/memos-local-plugin/adapters/hermes/memos_provider/bridge_client.py from (agent, no_viewer, runtime_home) to (agent, no_viewer, runtime_home, owner_id) so concurrent MemTensorProvider instances in one Hermes gateway process (email threads, cron jobs, subagents) stop reaping each other's bridge subprocesses.

Changes:

• bridge_client.py: adds owner_id: str | None = None to MemosBridgeClient.__init__; stores self._singleton_owner = owner_id or f"anon-{id(self)}"; widens _ACTIVE_CLIENTS type annotation to dict[tuple[str, bool, str, str], MemosBridgeClient]; _register_active / _unregister_active build the four-tuple key.
• adapters/hermes/memos_provider/__init__.py: both provider construction sites (initialize() and _reconnect_bridge()) in shared and legacy bridge modes now pass owner_id=f"provider-{id(self)}".
• tests/python/test_bridge_client.py: adds three regression tests — distinct owners coexist without displacement, same-owner replacement still reaps predecessor (preserves Bridge process leak: every turn spawns new bridge.cjs, 4+ processes accumulated #1910 guarantee), anonymous fallback yields unique keys per instance. Updates the two existing Bridge process leak: every turn spawns new bridge.cjs, 4+ processes accumulated #1910-era tests to pass explicit owner ids.

Verification: python3 -m unittest discover -s tests/python → 126 tests pass, 0 failed, 0 errored. Full log excerpt: "Ran 126 tests in 17.707s — OK". No production tests removed; only two pre-existing #1910 unit tests widened to assert on the four-tuple key.

Expected steady state after deploy: daemon + 1 bridge per host process = 3 total instead of 2 bridges churning every 2-3s; reconnect counts approach zero. Related history: #1910 (bridge process leak, now defended alongside #2291), #1927 (double-initialize), #1985 (HTTP transport, the eventual architectural end-state).

Base branch: main
Branch: bugfix/autodev-2291-20260827191701124
Commit: 8dc5bf9
PR: #2293
Assigned to: @Wang-Daoji
Reviewers: @WeiminLee