app

Adom Hydrogen

Public Made by Adom

by adom

The whole Adom experience as one signed native app: your editor, your AI agent, and the full electronics design toolchain, running locally on your own machine.

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

First-run setup cascade halts after step 10: test-direct-connect gate fails (workspace can't reach ab; relay 8765 down, ab spawned token-less)

kaleymer · 2mo ago ·closed by John Lauer

Setup cascade halted after step 10 — test-direct-connect gate failed (completed 10/21)

On a fresh ah (Hydrogen) first-run today (2026-08-11, build 2586b87f-dirty, v1.0.30, Windows / WSL2 mirrored networking), the auto-run setup cascade halted at the test-direct-connect gate after completing 10 of 21 steps:

10:44:00.158 [run_all_wsl] HALT: step 'test-direct-connect' failed after 3 attempts; not advancing to later steps
{"completed":10,"failed":1,"failures":[{"step":"test-direct-connect","error":"✗ direct connect (adom-bridge-cli ping) NOT confirmed in 60s, the workspace can't reach Adom Bridge on this host. HALTING (this step is a gate)."}],"ok":false,"total":21}

Full hydrogen-desktop.log attached (422 lines, covers the whole run).

What the log shows leading up to the halt

  1. The cascade started while Adom sign-in was still in flight. 10:25:00 [wsl-startup] state=never-run → auto-running setup cascade came 3 seconds after the sign-in browser intent opened; the log itself notes "Adom sign-in in flight (no session token yet)".
  2. ab was spawned token-less. 10:25:14 [ad-supervisor] spawned AB pid=19356 (token=absent).
  3. The local relay never came up. 10:25:08 [ad-relay] relay STILL down after restart (ws:8765 http:8766) and [ad-supervisor] relay :8765 not answering at supervisor start — ab will show red until it recovers. It never logged a recovery.
  4. ab was flaky the whole session — repeated [ad-supervisor] AB health probe failed (1/3 consecutive) - debouncing at 10:29, 10:34, 10:35, 10:37.
  5. Hydrogen itself restarted mid-gate: a fresh === Hydrogen Desktop started at 2026-08-11 10:42:22 === banner lands between ping attempt 1 (10:41:31) and attempt 2 (10:42:38), rebinding ports (control 47084, deprecated direct-api shim on 8770).

So the gate did its job — the workspace genuinely couldn't reach ab — but the failure looks self-inflicted upstream: ab was spawned without a session token before sign-in completed, its relay (ws:8765/http:8766) never recovered, and an app restart mid-gate reset whatever state the probe had.

Suggestions

  • Gate the cascade's ab-dependent steps (or at least test-direct-connect) on sign-in completion / token presence, or re-spawn ab with the token once auth lands.
  • Surface the [ad-relay] relay STILL down condition as a cascade failure earlier, rather than letting 10 steps succeed and burning 3×60s pings against a relay that was already known-dead at 10:25.
  • After the halt, the cascade state persisted as in-progress (persisted setup-state.txt = in-progress) — a halted-at-gate state distinct from in-progress would make retries/telemetry clearer.

Reported from container "Cosmiic" via ab relay; happy to pull more diagnostics (hd_status, bridge logs) on request.

hydrogen-desktop.log

3 Replies

kaleymer · 2mo ago ·edited

Follow-up with resolution context, so the thread has the full story.

Outcome first: the setup DID complete. A later pull of the same log shows ah's auto-resume recovered it — at 11:18:30 the Claude sign-in finally landed ("claude authorized after 576s"), and [auto-resume] both sign-ins satisfied + cascade incomplete + idle — resuming setup (run_all) so a late sign-in never leaves you stuck re-ran the cascade, which finished clean at 11:20:40: {"completed":20,"failed":0,"ok":true,"total":21}, setup-state.txt = complete. So the halt reported above was transient and the auto-resume design worked exactly as intended. 👏

That confirms the root cause: the cascade's first run started while sign-in was still in flight, and everything passed once both sign-ins were satisfied. This downgrades the report from "setup fails" to a first-run UX papercut — the user sees a scary HALT at step 10/21 for ~35 minutes until the late sign-in completes, when the log already knew at 10:25 that no session token existed yet. The suggestions in the report (gate ab-dependent steps on sign-in / fail fast on a known-dead relay instead of 3×60s pings) still stand as ways to avoid surfacing the halt at all.

Unrelated fix made while diagnosing (cloud-container side): the cloud container's relay ports (ws:8765/http:8766) were held by a stale adom-desktop serve process running since July 8 (pre-rename build). It answered /health fine but rejected the renamed adom-bridge-cli user-agent, so CLI verbs failed with direct_http_use_cli_instead while a freshly supervised 2.0.24 relay silently lost the port fight. Killing the stale process and restarting adom-bridge-cli serve --supervise fixed it; the desktop auto-reconnected in seconds (~26ms pings). Not the cause of the local test-direct-connect gate, but the same failure shape — a stale pre-rename process shadowing a healthy new one — and may be worth a supervisor-side detection in ah too.

John Lauer · 2mo ago

We believe this is FIXED — please retest on current versions.

Root cause class: the direct-connect gate depended on finding Adom Bridge's local API, which used to drift to a random ephemeral port whenever Windows reserved the old 47200 range (very machine-dependent — exactly the kind of box-specific failure you hit). Two shipped fixes close it: Adom Bridge 2.0.27+ binds a STABLE port (24680), and ah 1.0.41+ discovers it there (discovery-file first, then 24680, with service-identity validation).

Retest: update ah to 1.0.44 + let ab self-update (or reinstall both from the wiki), rerun setup. Fastest health readout: Adom menu → Doctor — the "Adom Bridge (direct)" row tells you instantly whether the exact channel this gate tests is healthy, and its hover text explains what it checks. If it still fails, the Doctor output is the perfect thing to paste here (with your ah + ab versions).

John Lauer · 1mo ago

Closing as verified fixed: test-direct-connect passed on both recent from-scratch installs, ConfRoomROG 2026-08-30 (20/20 cascade, zero failures) and the Azure VM 2026-08-31, with ab resolved on the stable port. Reopen with a log if it recurs on current builds.

Log in to reply.