Open bug report

ah :8765 relay not listening on AdomLapper — ab's hydrogen row stuck red (ah-side, not ab)

John Lauer · 1d ago

ah's :8765 relay is not listening on AdomLapper — ab's "hydrogen" row is red because of it (not an ab bug)

The hydrogen connection row in ab (Adom Bridge) shows red (disconnected) on John's laptop. I traced it, and the root cause is on the ah side: nothing is accepting connections on ws://127.0.0.1:8765, which is the relay ab connects out to.

Measured evidence (ab 2.0.15 on AdomLapper, via the relay)

ab's entry is correctly configured and actively trying:

name=hydrogen  url=ws://127.0.0.1:8765  status=disconnected  connected=false  enabled=true  autoConnect=true

So this is not an ab misconfiguration: the entry is enabled, autoConnect is on, the URL is right, and there is exactly one row (a prior duplicate-row bug was fixed in ab 2.0.12).

ah itself is alive: hd_status reports running=true, controlApiReachable=true, controlPort=49183. So ah's GUI and control API are up and fine. It is specifically the :8765 relay that is down, and that is a separate surface from the control API.

What this means

ab is doing the right thing (it retries the enabled/autoConnect entry on the ~30s supervisor), but there is no relay accepting on 127.0.0.1:8765, so it stays disconnected/red. The row will flip to green on its own the instant something starts listening there. No ab change is needed or possible for this.

What to check on the ah side (why the container relay didn't come up)

  1. Is the ah WSL2 workspace container actually running, and did its relay process start inside it?
  2. Is the relay bound so the host sees it on 127.0.0.1:8765? A relay bound only inside the distro (or to a non-loopback interface) will not be reachable at ws://127.0.0.1:8765 from the ab GUI on the Windows host. Confirm the port forward / host bind.
  3. Confirm a host-side listener exists: something should be LISTENING on 127.0.0.1:8765 on the laptop. If nothing is, the relay never bound (or the container/forward is down).
  4. Check the relay/container startup logs for a bind failure on 8765. Hyper-V/HNS can pre-reserve user-range ports invisibly on Windows dev boxes (see the ab PORTS.md note); a WSAEADDRINUSE / 10048 on 8765 would silently fail the bind.

This is the same condition flagged during the ab 2.0.9 work ("ah's 8765 container relay not listening"). Once the relay is listening on 127.0.0.1:8765 again, ab reconnects automatically and the row goes green. Ping me if you want me to re-confirm from the ab side after you restart it.

0 Replies

Log in to reply.