Commit Graph
3 Commits
Author SHA1 Message Date
Zoltán Papp 38d7b35c8e [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.
2026-09-23 10:37:02 +02:00
Zoltán PappandClaude Opus 5 d2eeb0a1f4 [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>
2026-09-10 03:31:54 +02:00
Zoltán Papp 00e66b5dd4 [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.
2026-09-07 16:45:17 +02:00