[Purple10101]

What

Every node is handed min_snr: 7.0 for retina-tracker, a setting nothing reads any more. This stops shipping it, drops the copy every node holds in user.yml, and makes sure removing it cannot crash the tracker.

Why

retina-tracker v0.5.0 tracks every detection. Its per-site SNR gate is gone (retina-tracker ed9bbea, "Track every detection: no per-site SNR threshold"), and a config that still sets min_snr is loaded and ignored. retina-gui stopped offering the field in retina-gui#119. Here, though, default.yml still shipped it and the merger still wrote it into retina-tracker.yaml.

Two things made "just delete the line" wrong:

• It would reach no node. The merger seeds user.yml with a whole copy of default.yml on first boot, so every node already holds retina_tracker: {min_snr: 7.0}, or whatever retina-gui wrote there. This is the same first-boot copy problem migrate_remove_tracker() and the other migrations solve.
• It would crash the tracker on every node. An empty retina_tracker: section reads as null, and the merger would have written tracker: null. retina-tracker's load_config() calls .update() on each section it finds, so that raises TypeError and the tracker crash-loops.

Fix

• config/default.yml: the retina_tracker section is removed, so the tracker runs on its own built-in defaults. A comment says how a section would map if one is added again.
• migrate_remove_min_snr(user):
  • Drops retina_tracker.min_snr from the user overlay at merge time.
  • Unconditional, like migrate_remove_tracker(), because the setting configures nothing.
  • Drops the section once it is empty, or if it is already empty or null.
  • Leaves user.yml on disk untouched, so it stays load-bearing and a Mender rollback regenerates the old config from the old default.yml.
• generate_retina_tracker_config():
  • Writes retina-tracker.yaml on every run, as {} when there is nothing to override, and never as tracker: null.
  • Before, an absent section skipped the write and left the previous merge's file on disk, still saying min_snr: 7.0.

Testing

• Tests:
  • The three generic retina-tracker.yaml tests move off min_snr to gate_threshold.
  • New tests cover the first-boot copy and a value retina-gui wrote, another tracker key surviving, an empty and a null section, a stale file being overwritten, user.yml left untouched, and the shipped default.yml.
  • Every tracker file is loaded through a mirror of retina-tracker's own load_config(), so a tracker: null would fail the test.
• CI's commands locally: pytest config-merger/test/ scripts/test/ gives 83 passed. ruff check . and the pre-commit dead-code hook are clean.
• On a test node with an RSPduo, using its real retina-config-merger:v0.4.8.0-dev and retina-tracker:v0.5.0 images, with the new script and default.yml mounted over the baked-in ones, against a copy of its real user.yml, writing to a scratch folder:
  • The merger logged "Dropping retina_tracker.min_snr (7.0) from user config" and wrote {}.
  • user.yml was unchanged.
  • The merged config.yml differed from the live one by retina_tracker.min_snr alone.
  • The tracker image loaded the {} file and fell back to its defaults.
  • As a control, the same tracker image crashed with TypeError: 'NoneType' object is not iterable on a tracker: null file.

Not verified: a full stack run with this merger in place. The merger image is only built at release, so the live stack on the test node was not touched.

Docs

retina-node has no docs/ folder, and the README does not mention the tracker section. The explanation lives in the default.yml comment and the two docstrings.

After this

• It reaches nodes with the next retina-node release, which bumps CONFIG_MERGER_V to its own tag as usual. The change is in the merger image, which bakes in default.yml.
• retina-tracker's docs/measurement-noise.md lists retina-node's min_snr as an outstanding follow-up, which can be closed once this ships.

🤖 Generated with Claude Code