truenas-truecloud-patch

Found live, in the code written to prevent exactly this.

The sidecar held ONE snapshot. So a run that reclaimed an older tree, failed to
finish reclaiming it, and then recorded its own snapshot OVERWROTE the only record of
the survivor -- orphaning it permanently.

Observed: job 24 left one snapshot busy and kept the sidecar (correct). Job 46
reclaimed it, hit ZFS's 300s automount window (the runs were minutes apart), left it
behind again, and then wrote its own snapshot over the record. Permanent orphan,
created by the safety net.

The sidecar is now a list. stage_nested carries forward whatever a reclaim could not
delete; cleanup_task sweeps every pending tree and writes back only the survivors.
cleanup_all reports them one per line instead of formatting a list into an f-string
at the user during uninstall.

Job 46 also confirms the automount fix itself: it swept all 256 of its own snapshots
with no straggler.

2026-07-13 19:35:44 +00:00

test_alert_source.py

v0.5.1: the update alert could have broken middlewared at startup

2026-07-13 16:52:23 +00:00

test_apply_blocks.py

Never touch CloudSync tasks; restore the logger the async cleanup path dropped

2026-07-13 18:30:35 +00:00

test_compat.py

compat: check the middlewared METHODS we call, not just the symbols we wrap

2026-07-13 18:25:14 +00:00

test_create_task.py

v0.3.3: keep the restic repo password out of argv and shell history