Top-bar update button applies the staged version and immediately re-prompts; it should resolve the latest at click time

Overview Files Skills Discover Packages Releases Dependencies Issues20 Breadcrumbs Pull Requests Activity

Closed general

Ray · 1mo ago ·closed by John Lauer

Reported by Ray on ROG-Zephyrus, 2026-09-10, in the Adom gchat, with John replying in thread.

What happens

Ray updates at least once a day and had updated the day before. He pressed the top-bar update button, it applied an update and restarted, and the top bar immediately offered another update. It nagged him to 1.0.322, he took it, and only then did it settle on 1.0.322.

What should happen

"It should check for the latest at the moment of the update button click, or get the updates more frequently... so that I only need to click it once and be set for that moment."

and, when asked whether he was using Settings > Adom menu > updater > Check now:

"I am not, and my point is that I shouldn't have to. Good UX is the update button in that top bar should grab the latest update automatically, inform me, and apply that."

The likely mechanism

John, in thread:

"i'm not totally sure how the ai is making those updaters work. i think sometimes it seems to cascade them, but i don't think it should have to. are you going to your settings under the adom menu, to the updater section, and hitting 'check now' cuz that should bring you to the latest version"

That points at two code paths with different behaviour: the top-bar button applies whatever version is already staged, while Settings > updater > Check now re-resolves against the server first. If a newer build was published after the current one was staged, the button installs the stale one and the next poll immediately offers the newer, which is the cascade Ray sees.

If that is the shape of it, either fix works and the first is better:

the top-bar button re-resolves the latest before applying, so one click always lands current; or
the stager always re-stages to the newest available, so nothing stale is ever the thing on offer.

Cascading is not inherently wrong when a migration genuinely has to run in steps, but John's own read is that these do not have to.

Not a duplicate of #68

adom/hydrogen#68 was the banner dismiss bug (one × hid every later version for the session) and shipped in 1.0.281. This is the opposite surface: the banner appears correctly, and the problem is which version the button installs.

Environment

ROG-Zephyrus, Windows/WSL2. adom-cli 0.5.18, Adom Bridge 2.1.96. Hydrogen ended on 1.0.322.

I could not capture GET /updater/status as evidence: the control API is not reachable from inside the container, so the sequence above is from the chat thread rather than from the updater's own state. Anyone on the host can grab it directly and it would confirm or kill the staged-vs-latest theory in one call.

3 Replies

Ray · 1mo ago

Cross-ref: the same session surfaced adom/hydrogen#74 (the WSL2 container-shift migration that has blocked this machine for two weeks) and a new symptom on adom/hydrogen#49 (sidebar visibility and pane widths do not survive a refresh). All three came out of one Adom gchat thread on 2026-09-10.

John Lauer · 1mo ago

Fixed and proven on the real branch, not by inference. Your diagnosis was exactly right, and the code said so: apply_staged() filtered the staged marker only on version_gt(staged, CURRENT) and "the file exists". It never asked what the LATEST was. So a build published after the stage was taken got installed anyway, the next poll found the newer one, and you got the cascade. Settings > Check now differed for precisely the reason you guessed: it re-resolves first.

Shipped in 1.0.327 (insiders). The top-bar button now re-resolves at click time, bounded at 10 s so it can never hang on a slow or missing network; on timeout it applies what is staged, the old behaviour, and logs why. If the published version is newer than the stage, the stale stage is discarded and the latest is fetched.

Proof on arav-rog, set up as your exact state (a stage taken before a newer build shipped): running 1.0.327, a staged marker claiming 1.0.328 pointing at a real installer, 1.0.329 published. One POST /updater/install, which is the call the banner button makes:

13:17:22.872 Update available: 1.0.327 -> 1.0.329 (manifest from .../adom/insiders/.../version.json)
13:17:22.873 [updater] staged 1.0.328 is behind the published 1.0.329: installing the latest instead, one click (hydrogen#73)
13:17:22.874 Downloading installer .../1.0.329/Adom.Hydrogen_1.0.329_x64-setup.exe
13:17:23.536 SHA256 verified

The box came back on 1.0.329. One click, no stepping.

One thing worth flagging because it nearly fooled me: my first run looked like a pass and was not. PowerShell's Set-Content -Encoding UTF8 writes a byte-order mark on 5.1, serde_json refuses it, and the marker was silently judged unusable, so that run took the no-usable-stage fallback rather than the branch under test. It still landed 1.0.329, because that fallback now reads the manifest the click-time re-check just refreshed, but it proved the wrong thing. Rewritten with File.WriteAllText before the result above was accepted.

John raised the same complaint from the team independently, and asked whether it was a timing artefact of the four-hour poll. It is, in the sense that the poll decides what gets staged; the fix removes the dependency on when that poll last ran, because the click itself now re-resolves. Your "I shouldn't have to" was the right call: Check now is no longer a thing to know about.

John Lauer · 1mo ago

Closing. Fixed and proven in 1.0.327 (the top-bar button re-resolves the latest version at click time; see the proof run above), and no cascade has been reported since. Reopen if a click ever installs a stale version again.