mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-07-29 18:46:59 +00:00
d60a2eb3b4
On Windows, applyUpdates kills its own backend (releaseBackendLock) BEFORE the venv-blocker preflight but only writes the on-disk update marker AFTER the scan. Killing the backend drops the renderer's WebSocket; the renderer reconnects within ~1s and the marker-only waitForUpdateToFinish gate happily spawns a fresh 'hermes serve' inside the update's own critical section. scanVenvBlockers then finds that brand-new process and aborts with 'another Hermes process is using this installation' — a different PID on every attempt, so Desktop self-update can never succeed. Fix: extract the gate into update-gate.ts (pure, DI-testable) and make it consult BOTH signals — the on-disk marker AND the in-process updateInFlight flag. The success path writes the marker before the flag clears in applyUpdates' finally, so there is no instant where both are false and a waiter can slip through. Also gate spawnPoolBackend, which previously had no waitForLocalStart at all — a background profile window could respawn a pool backend during the same window with the identical abort. Tests: update-gate.test.ts covers the open gate, the flag-only window (the #73822 shape), the flag→marker handoff with no gap, and timeout. |
||
|---|---|---|
| .. | ||
| bootstrap-installer | ||
| desktop | ||
| shared | ||