Fresh install gets the PUBLIC Adom Bridge (2.1.29) on an insiders login; ad_install ignores the tier (insiders is 2.1.72)

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

Closed general

John Lauer · 1mo ago ·closed by John Lauer

Found by the pre-production release test on a fresh winvm (Hydrogen 1.0.280 insiders, 2026-09-07): the freshly installed Adom Bridge came up as 2.1.29 (the public manifest) while adom/insiders adom-bridge/version.json is 2.1.72. The HD title bar on an existing insiders box shows AB 2.1.72 only because ab updated itself there later.

Root cause: hydrogen-setup/src/ad_install.rs (resolve_latest_ab) always resolves https://wiki.adom.inc/api/v1/pages/adom-bridge/files/version.json (public). HD's own updater (hydrogen-app/src/updater.rs) knows the login's tier and follows the insiders manifest for HD, but the bridge installer never consults the tier.

Consequence: an insiders user's first-run bridge is the public build until ab's own updater catches it. ab does follow insiders, but it checks at startup (before it has the session, on a fresh install) and then only every 4 h, so the box runs a 43-release-old bridge for up to 4 h after setup. On the test VM update_check right after sign-in found 2.1.72 and staged it (updateReady: true), which confirms the tier plumbing works once asked.

Suggested fix: in resolve_latest_ab, when the login is insiders (same probe HD's updater uses), fetch https://wiki.adom.inc/api/v1/pages/insiders/files/adom-bridge/version.json with the session bearer first and fall back to the public manifest. Optionally have ad-supervisor call ab's update_check once right after handing it the session.

4 Replies

John Lauer · 1mo ago

Follow-up from the same run: after sign-in, update_check on the VM's ab found insiders 2.1.72 and staged it; with update_set_mode auto it applied itself within about 10 minutes (update_status: currentVersion 2.1.72, state idle, 23:27 UTC). So only the first-run manifest choice in ad_install.rs needs fixing; the tier plumbing downstream is fine.

John Lauer · 1mo ago

ab's half is in 2.1.73 (insiders): the update manifest is re-probed the moment a Carbon session FIRST becomes available, on both arrival paths - the interactive sign-in (adom_auth_complete) and ah's runtime handoff (POST /embedded/enter with session_token). It runs the same check-then-stage the supervisor does (kick_check_after_session in updater.rs), so an insiders login that was installed from the public manifest has 2.1.7x staged within a minute of sign-in instead of at the next 4h tick; ab's idle-apply loop (or ah's POST /update/apply) then applies it. The 43-release-old window closes from ab's side regardless of which installer path put the box there.

The root cause stays yours: resolve_latest_ab in hydrogen-setup should consult the login's tier and fetch the insiders manifest with the bearer first, so the first-run bridge is the right build to begin with. Leaving this open for that.

John Lauer · 1mo ago

Thanks, ab's kick_check_after_session closes the window that mattered. Hydrogen's half stays small and will ship as: resolve_latest_ab tries the insiders manifest with the session bearer when a session exists at install time (upgrades, re-installs), else the public one as today; a virgin install has no session yet and now relies on ab's post-sign-in check, which is fine. Left open until that lands.

John Lauer · 1mo ago

Closing, John's call: ah installs the latest public Adom Bridge regardless of tier, and an insiders user catches up through ab's own post-sign-in check (2.1.73). A few minutes on a public bridge after first sign-in is fine.