An upgrade leaves the old daemon running and the new MCP server silently attaches to it #591

New issue

Open

opened 2026-11-14 20:02:50 +01:00 by buildagent · 0 comments

buildagent commented

2026-11-14 20:02:50 +01:00

Member

Report

From the zammad-dev field report of 2026-11-08 (v0.41.44 → v0.41.45), found again during dogfood triage batch 25 and not tracked by any open issue:

owner installed it while the 0.41.44 daemon kept running from the deleted binary — the new MCP attached to the OLD daemon; I stopped it (SIGTERM, exited cleanly) and MCP spawned 0.41.45. […] an upgrade does not replace a running daemon — the MCP silently keeps talking to the old one.

Why it matters more now

A daemon that survives an upgrade spawns the newly installed worker binary. v0.42 bumps the worker protocol version, so such a pair refuses each other at the handshake (clean, but every extraction is then unavailable until the daemon is restarted), and nothing tells the user that the cause is a daemon older than the installed release.

Acceptance

A client (MCP server, CLI) that finds a daemon of another build than its own says so in the payload it already has for daemon state, with the two versions and the one command that fixes it.
Decide and document one behaviour for an upgrade under a running daemon: the installer stops registered daemons, or the next client replaces a daemon of an older build, or the mismatch is only disclosed. Test the chosen one end to end.
install.sh / install.ps1 output names the running daemons it found, if any.
Not re-tested on v0.41.53; #584 (closed) fixed a different symptom of an old daemon (filters refused after a restart).

## Report From the zammad-dev field report of 2026-11-08 (v0.41.44 → v0.41.45), found again during dogfood triage batch 25 and not tracked by any open issue: > owner installed it while the 0.41.44 daemon kept running from the deleted binary — the new MCP attached to the OLD daemon; I stopped it (SIGTERM, exited cleanly) and MCP spawned 0.41.45. […] an upgrade does not replace a running daemon — the MCP silently keeps talking to the old one. ## Why it matters more now A daemon that survives an upgrade spawns the newly installed worker binary. v0.42 bumps the worker protocol version, so such a pair refuses each other at the handshake (clean, but every extraction is then unavailable until the daemon is restarted), and nothing tells the user that the cause is a daemon older than the installed release. ## Acceptance - A client (MCP server, CLI) that finds a daemon of another build than its own says so in the payload it already has for daemon state, with the two versions and the one command that fixes it. - Decide and document one behaviour for an upgrade under a running daemon: the installer stops registered daemons, or the next client replaces a daemon of an older build, or the mismatch is only disclosed. Test the chosen one end to end. - `install.sh` / `install.ps1` output names the running daemons it found, if any. - Not re-tested on v0.41.53; #584 (closed) fixed a different symptom of an old daemon (filters refused after a restart).

buildagent added the

Kind/Bug

label

2026-11-14 20:02:50 +01:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

h-dv/code-index#591

No description provided.

Rows
Columns