[Bug] memos-local-plugin: --daemon entry never starts the status heartbeat — health reports "stale" forever while RPC works

[chiefmojo]

Bug report

Summary

Since #1998, the Hermes launcher prefers the pure-ESM dist/bridge.mjs entry over dist/bridge.cjs. However, bridge.mts only starts the bridge-status.json status heartbeat in its stdio branch (if (!args.daemon)). The --daemon branch never calls markConnected() / startHeartbeat() — so no daemon ever refreshes the status file.

The legacy bridge.cts daemon path has both calls right after the viewer port binds; the ESM successor lost them in translation.

Impact

Any --daemon spawn writes no status updates. Readers (health endpoint, external monitors) apply the 20s staleness rule to whatever snapshot is on disk and permanently report:

status: "disconnected"
lastError: "Hermes bridge heartbeat is stale"

…while the bridge is actually healthy: RPC (POST /api/v1/rpc) keeps working normally because it never touches status tracking. Monitoring built on the health endpoint therefore shows a dead bridge during fully functional operation.

Repro

1. node dist/bridge.mjs --agent=hermes --daemon
2. Watch <home-root>/bridge-status.json: once stale from a previous run, its mtime/content never changes again after daemon start (no initial write either)
3. ~20s later, the health endpoint reports bridge.status: disconnected, "Hermes bridge heartbeat is stale" — indefinitely

Observed in production after a v2.0.7 → v2.0.16 jump: the status file froze at the pre-upgrade daemon's last write, and every respawned daemon (fresh PID) left it untouched.

Root cause

apps/memos-local-plugin/bridge.mts — markConnected() / startHeartbeat() appear only inside if (!args.daemon). The if (args.daemon) block has none. Compare bridge.cts, which calls both after successful viewer bind in daemon mode.

Suggested fix

Mirror the .cts daemon path — two lines after the bind-retry loop succeeds:

bridgeStatus?.markConnected();
bridgeHeartbeat = bridgeStatus?.startHeartbeat();

PR incoming with the fix plus a source-level regression guard test (same pattern as the existing bridge-startup-ordering.test.ts).

[Memtensor-AI]

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

Task ID: 143f598f8eb246dd
Working branch: bugfix/autodev-2278-20260823133455125
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.

[Memtensor-AI]

✅ AutoDev task 143f598f8eb246dd completed.

Summary: Fixes #2278: the memos-local-plugin --daemon bridge entry never started the bridge-status heartbeat, so a daemon-spawned bridge never refreshed bridge-status.json and the health endpoint permanently reported "Hermes bridge heartbeat is stale" while RPC kept working.

Root cause: the pure-ESM entry apps/memos-local-plugin/bridge.mts (built to dist/bridge.mjs, which the Python launcher has preferred since #1998) only called markConnected() / startHeartbeat() inside its stdio branch (if (!args.daemon)); the --daemon branch had no status calls at all. A source-level git-history check confirmed the legacy bridge.cts daemon path had the same gap (never called there even in the original signal-light commit 22ccacb), which is why the ESM translation lost it.

Fix: mirror the stdio pattern into the daemon branch of both entries — after the viewer bind-retry loop succeeds, call bridgeStatus?.markConnected() and bridgeHeartbeat = bridgeStatus?.startHeartbeat(); stop the heartbeat in shutdownDaemon (SIGINT/SIGTERM). The bridge core is fully initialized before the daemon block, so "connected" is never claimed prematurely; OpenClaw is unaffected (all calls are ?.-guarded no-ops since bridgeStatus is null for openclaw); the heartbeat timer is unref()ed and does not hold the daemon open. Stdio-mode behavior is unchanged and pinned by the new regression test.

Regression guard: added apps/memos-local-plugin/tests/unit/bridge/bridge-daemon-heartbeat.test.ts, a source-level guard following the existing bridge-startup-ordering.test.ts pattern (#1747). It asserts both entries start the heartbeat inside the if (args.daemon) branch while the stdio branch keeps its own calls. Verified TDD-style: the test fails on the pre-fix code (both entries) and passes after the fix.

Test evidence (real output): vitest run tests/unit/bridge tests/unit/bridge-status.test.ts -> 8 files / 39 tests passed; tsc -p tsconfig.json --noEmit -> exit 0; vitest run tests/unit -> 164 files / 1351 passed, 1 skipped. (An initial full-suite run showed failures in unrelated modules caused by pnpm skipping native build scripts locally — better-sqlite3/esbuild/onnxruntime/sharp; after approving those builds the entire suite is green. The change touches only bridge.mts, bridge.cts, and the new test.)

opsp artifacts archived to the memos-autodev-specs repo (task.md + proposal/spec/design/tasks/test-cases/verification-report) on commit b89a59e.

Base branch: main
Branch: bugfix/autodev-2278-20260823133455125
Commit: 223fc8f
PR: #2280
Assigned to: @CarltonXiang
Reviewers: @whipser030, @hijzy