Skip to content

20260913 - Let the new tracker_forward default reach deployed nodes - #38

Merged
Purple10101 merged 1 commit into
mainfrom
20260913-migrate-tracker-forward
Sep 13, 2026
Merged

Purple10101 merged 1 commit into
mainfrom
20260913-migrate-tracker-forward

Conversation

@Purple10101

Copy link
Copy Markdown
Collaborator

Issue

4ed672e pointed tracker_forward at blah2_api (127.0.0.1:30100) instead of the old retina-gui path (blah2_tracker:3012). That change cannot reach any node that has already booted.

The merger seeds user.yml from default.yml on first boot, so every node on the estate holds its own copy of whatever block shipped at the time, and the user layer wins over the default. This is the same failure migrate_doppler_span() was written for.

Design

migrate_tracker_forward() drops the block from the user layer when it is exactly the one we used to ship, so the shipped default applies again. Three deliberate choices:

  • Matches the whole legacy triple, not just enabled. A node aimed at some other host or port made a real choice and is left alone.
  • Deletes the keys rather than rewriting them, so a later change of host or port also lands.
  • Leaves user.yml on disk untouched, so the migration stays load-bearing rather than becoming a one-shot fixup that silently stops mattering.

Narrower and safer than the Doppler case: blah2_tracker is a compose service name, and these nodes run blah2-api with network_mode: host where it resolves to nothing. A node deliberately pointed there was already not forwarding, so nothing that currently works is being taken away.

Verification

39 tests pass, ruff check clean.

Nine new tests cover the migration itself, the four cases that must be left alone (deliberate target, deliberately disabled at the new address, partial legacy match, an extra key added by hand), forced.yml still winning, user.yml staying untouched on disk, and a user config with no block at all.

The exact-match constant is safe because only two variants were ever shipped: 2a2ce6d introduced the legacy triple and 4ed672e replaced it. A node that first booted before 2a2ce6d has no key at all and also lands on the default.

Release ordering

This turns forwarding on, so it wants to ship alongside a blah2 build carrying the frame delimiter fix (860f73f, two commits past v0.4.3) and a retina-gui that has stopped forwarding, since the tracker's ingest socket accepts one connection at a time. Against an older blah2 the migration is inert rather than harmful: those nodes were not forwarding before and still will not be.

Note this migration ships inside the config-merger image, so it only starts running once that image is rebuilt and CONFIG_MERGER_V is bumped.

🤖 Generated with Claude Code

Detections reach the tracker from blah2_api now rather than retina-gui, but
the node that changed default.yml could not move a node that had already
booted. The merger seeds user.yml from default.yml on first boot, so every
node on the estate persists the block that shipped at the time and overrides
whatever we ship later. Same problem migrate_doppler_span() solves.

Drop the block when it is exactly the one we used to ship, so the shipped
default applies again. Only the whole legacy triple matches: a node aimed at
some other host or port made a real choice and is left alone. Deleting the
keys rather than rewriting them means a later change of host or port also
lands, and user.yml on disk is untouched, so this stays load-bearing rather
than becoming a one-shot fixup.

Narrower than the Doppler case. 'blah2_tracker' is a compose service name and
these nodes run blah2-api with network_mode host, where it resolves to
nothing, so a node deliberately pointed there was already not forwarding.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Purple10101
Purple10101 merged commit b4445e4 into main Sep 13, 2026
1 check passed
@Purple10101
Purple10101 deleted the 20260913-migrate-tracker-forward branch September 13, 2026 16:23
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