* [client] Keep the updater silent until management decides the mode
The update manager started in download-only mode and every engine stop
reset it there again, kicking the update loop with the cached latest
version. On a managed peer this published a "New version available"
notification on each disconnect, session expiry or logout, and once more
in the window between daemon start and the first network map. Users under
enforced updates then installed the release by hand.
Replace the boolean with a three-state mode. The manager starts undecided
and publishes nothing, from the fetcher or from NotifyUI, until the network
map picks download-only or managed. A new connection lifecycle resets to
undecided; disconnects leave the last decision untouched. A missing
AutoUpdateSettings now means download-only instead of a no-op, and on
platforms without an installer SetVersion falls back to download-only so
they keep notifying.
* [client] Address review findings on the updater mode split
Route every mode transition through one locked helper so the staged
managed version cannot outlive the decision that created it. Both
download-only transitions kept pendingVersion, letting Install put on
the old enforced release after management disabled updates or the
platform fell back to download-only.
The helper also bumps a generation counter. handleUpdate and NotifyUI
copy the mode under the mutex but publish and install after releasing
it, so a reset landing in that window could still emit an enforced
notification. Both now recheck the generation right before the side
effect and drop the stale work.
Reset on every connection attempt instead of once per run: the backoff
loop reconnects without re-entering run, and since disconnects no longer
force download-only, a fetch in the disconnected gap republished the
enforced notification before the new network map arrived.
A missing AutoUpdateSettings now logs that it defaults to download-only
rather than claiming auto-update is disabled, which contradicted the
notifications that mode still emits.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* [client] Reset the updater mode on engine stop
Removing SetDownloadOnly from the engine teardown also dropped the reset of
the forced-update flag. After netbird down the manager kept the last
management directive, so a release published while the client was stopped
could still trigger a forced install that management no longer asked for.
The same window existed between an engine teardown and the next reconnect
attempt, where ResetMode only ran at the start of the attempt.
Reset the mode in stopLocked instead, so the updater stays silent from the
moment the engine goes down until the first network map of the next
connection decides the mode again.
* [client] Name the force-reset test for the behavior it proves
The silence after ResetMode follows from the undecided mode alone, and the
closing SetVersion overwrites forceUpdate from its argument, so the test
cannot observe whether the flag itself was cleared. Name it for the stale
directive staying silent, which is what it asserts.
* [client] Fall back to download-only on a malformed expected version
* [client] Compare the full auto-update directive before skipping it
* [client] Set the mock latest version under its lock in the updater tests
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Auto-update logic moved out of the UI into a dedicated updatemanager.Manager service that runs in the connection layer. The
UI no longer polls or checks for updates independently.
The update manager supports three modes driven by the management server's auto-update policy:
No policy set by mgm: checks GitHub for the latest version and notifies the user (previous behavior, now centralized)
mgm enforces update: the "About" menu triggers installation directly instead of just downloading the file — user still initiates the action
mgm forces update: installation proceeds automatically without user interaction
updateManager lifecycle is now owned by daemon, giving the daemon server direct control via a new TriggerUpdate RPC
Introduces EngineServices struct to group external service dependencies passed to NewEngine, reducing its argument count from 11 to 4
