Skip to content

fix: generate random machine ids to prevent fleet state clobbering#12

Open
paddo wants to merge 4 commits into
mainfrom
fix/onboarding-machine-id-collision
Open

fix: generate random machine ids to prevent fleet state clobbering#12
paddo wants to merge 4 commits into
mainfrom
fix/onboarding-machine-id-collision

Conversation

@paddo
Copy link
Copy Markdown
Contributor

@paddo paddo commented May 16, 2026

Summary

  • machine_id was derived from the hostname, so two machines sharing a hostname also shared a machines/<id>.json record. The second machine's first sync overwrote the first's state with empty local data, and removed-package detection then flagged the whole fleet's packages as deliberately removed.
  • machine_id is now a random hex id minted once per machine. Collisions are no longer possible; the hostname is purely display metadata on MachineState. Existing machines keep their hostname-based id (already persisted in state.json), so there is no migration.
  • Re-onboarding a machine now produces a fresh id (a harmless "ghost" record removable via tether machines remove) rather than risking a clobber.
  • Also surfaces pnpm errors written to stdout: pnpm exits non-zero with its message on stdout, so failures previously showed a blank reason.

Test plan

  • Fresh tether init mints a random machine_id; a second machine with the same hostname gets a distinct id and does not overwrite the first's record
  • An already-onboarded machine keeps its existing id across syncs and reinit
  • tether machines list / remove still work with the new ids
  • A failing pnpm command surfaces the real error text instead of a blank message

paddo added 2 commits May 16, 2026 19:28
A machine_id is derived from hostname, so onboarding a machine that
shares a hostname reused an existing machines/<id>.json record. The
new machine's first sync overwrote it with empty local state, which
detect_removed_packages then flagged as deliberate removals across
the fleet.

init now detects an existing machine record before the first sync and
asks whether it is the same machine or a new one, assigning a unique
id when new.

Also surface pnpm errors written to stdout: pnpm exits non-zero with
the message on stdout, so failures previously showed a blank reason.
Deriving machine_id from the hostname meant two machines sharing a
hostname also shared a machines/<id>.json record — the second machine's
sync overwrote the first's state. The previous interactive collision
check only narrowed the window and still mishandled a genuinely
re-onboarded machine.

machine_id is now a random hex id minted once per machine. Collisions
are no longer possible and the hostname is purely display metadata on
MachineState. Existing machines keep their hostname-based id since it
is already persisted in state.json.
@paddo paddo changed the title fix: prevent new machine from clobbering fleet state on init fix: generate random machine ids to prevent fleet state clobbering May 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant