Adom Hydrogen
Public Made by Adomby 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.
Setup telemetry v2: find out why installs fail and where people give up
Why
Setup telemetry v1 (1.0.512+) tells us which step failed. It does not tell us why, and it cannot tell a slow download from someone giving up, a crash from a quit, or an installer that never got as far as opening Hydrogen. Our most common failure is ensure_workspace_failed_import right after a fresh WSL install, and today we cannot say whether those machines have virtualization off, the VM platform not ready yet, or something else.
The fleet dashboard already accepts and renders every signal below (deployed 2026-10-07), so each one shows up the moment a build sends it. Ship them in any order; the list is ranked by how much each one tells us.
Wire rules (same as v1)
- Same transport: POST to the
fleet_urlfrom the manifest, same body as today (product,version,tier,machine,os,install_id,user_id/usernameonce signed in) pluseventand the fields below. - All values are strings, each at most 120 characters. Fire and forget, never block setup on a ping, never retry more than once.
install_idon every event, so all of it joins into one attempt.- None of these events count as an update check (the dashboard already treats anything with
eventset as funnel only).
1. Sub-phases inside ensure-workspace (event: setup_phase)
ensure-workspace is 3 different jobs. Ping each one with step: "ensure-workspace", phase, state: start | ok | fail, ms on ok and fail, error on fail.
| phase | where (hydrogen-runtime wsl.rs fresh_import) |
|---|---|
wsl_install |
wsl --install and its UAC prompt |
image_download |
download_tarball |
image_checksum |
verify_tarball_sha256 |
wsl_import |
wsl --import Adom-Workspace ... --version 2 |
first_boot |
first start of the distro until code-server answers |
On fail, also send exit_code (the process exit code) and hresult (the Wsl/Service/... or 0x8037... code from stderr, if present). That one field should answer the import question: for example 0x80370102 usually means virtualization is off in firmware.
2. Download progress (event: progress)
During image_download, every 10% (not more often): phase: "image_download", pct, bytes, total, bps (bytes per second averaged over the last 10%). The dashboard turns this into Mbps and shows finish rate by connection speed, and the exact percent a person was at if they quit.
3. Heartbeat (event: heartbeat)
While any step is running, every 60 seconds: step, phase and pct if known. Without it, a slow 20-minute import and an abandoned window look identical. The dashboard calls an attempt "in progress" while heartbeats are under 3 minutes old and "went silent" after that.
4. Quit during setup (event: quit)
When the window closes or the app exits before setup_complete: step, phase, pct. Send it synchronously with a short timeout (500 ms) before exit. This is the difference between "they gave up" and "it broke".
5. Crash report on next launch (event: crash_report)
Write the current step/phase to a small marker file when each starts, delete it on setup_complete and on clean quit. If the marker exists at the next launch, the previous run died: send crash_report with prev_step, prev_phase, then continue as normal.
6. System profile on first launch
Add these fields to the existing first_launch ping (and only that one):
| field | value |
|---|---|
win_edition |
Home, Pro, Enterprise, Education, ... |
win_build |
e.g. 26100 |
ram_gb |
total RAM, whole GB |
disk_free_gb |
free GB on the drive the workspace goes to |
virt_fw |
yes / no, firmware virtualization (the existing pre-check in setup_steps.rs 678-688 already computes this) |
hypervisor |
yes / no, hypervisorPresent |
wsl_present |
yes / no, before we do anything |
wsl_version |
from wsl --version if present |
The dashboard shows finish rate by each of these.
7. Installer and uninstaller pings (event: installer, event: uninstall)
Today we only hear from people once Hydrogen opens. The NSIS installer should:
- create the
install_id(GUID) and write it to%APPDATA%\hydrogen-desktop\install-id.txt; the app reuses it instead of making its own when the file exists, - ping
installerwithstate: startwhen it begins andstate: okorstate: fail(withreason, e.g.disk_full,cancelled,access_denied) when it ends.
The uninstaller pings uninstall with the same install_id (and reason if we ever add a "why are you leaving" box). The dashboard then shows "installed, never opened" (installer ok, no first launch after 30 minutes) and uninstalls.
8. Slow step (event: slow)
When a step or phase passes 3x its expected time, ping once: step, phase, ms so far, expected_ms. Suggested expectations: image_download 300000, wsl_import 90000, first_boot 60000, everything else 30000.
9. Error screens and what people press (event: error_screen)
When setup shows an error to the person: screen (a stable id like virtualization_off, import_failed, no_network), step. When they press something on it, send again with button (retry, help, quit). This tells us whether our recovery screens actually recover anyone.
10. Sign-in screen and first use
event: signin_screenwithstate: shown | opened_browser | cancelled | timed_out,reasonif any. Today the sign-in wait is only a span; this says whether they bounced off it.event: first_usewithactionthe first time each happens after setup:opened_editor,first_ai_prompt,opened_project. Once each, ever, per install.
11. Exact sign-up join (needs the auth side)
Pass install_id as a query parameter on the sign-in URL Hydrogen opens, so the account created from it records which install it came from. Then a new sign-up joins to its install exactly, instead of us matching by time and IP. This needs a small change on the auth side too; just add the parameter on this side and note it here.
Real attempts to check against once it ships
Import failures right after a fresh WSL install (the hresult from item 1 should explain these):
559561a2-b04f-4911-a9a6-60dda65f255ce8beae4d-262b-4d28-bd33-ec595360494f20283108-0fd3-4561-961d-9f75fe199480e459a7de-4344-4d4c-bea6-75da2489af1886472acc-38aa-4653-8506-b88b8463f03e(our test VM with virtualization deliberately off: expectedvirt_fw: no)76b8b50e-44fd-4ad9-8eec-c974b4111412(wsl_install_exit_1)
Went silent at the start of ensure-workspace with no failure (heartbeat, quit and crash_report from items 3 to 5 should explain these):
a8cf1aeb-1bbf-4057-af0b-eb174416b1a466dbc780-7caf-44f0-88f6-a877c09f5513f42669d9-3ca9-47ad-bdb7-97754dbd0d25d53e14c2-1358-49b5-a1b0-9a9c8624fac6
Done when
Ship to insiders, run one install on a clean Windows VM, and check the Setup funnel tab shows the system profile, the download speed, the sub-phase it stopped at, and the new sections. Reply here with the build number and the install_id of that test and I will confirm each signal landed.