venus
VENUS-355
venus-db-backup.sh prune glob crosses lanes — retention 84 total not 84 encrypted; effective 6 days not 7
Done normal
bvbin-venus-cc
venus-db-backup.sh prunes with glob venus-prod-*.sql.gz*, matching the LEGACY PLAINTEXT .sql.gz artifacts as well as current .sql.gz.gpg ones. VENUS_DB_BACKUP_KEEP=84 is therefore 84 files across BOTH lanes, not 84 of this lane's. Effective encrypted retention today is 73 files (~6 days), not the 7 days the constant claims — and the lane has been deleting another lane's artifacts as a side effect (25 legacy files; that is what the 'pruned 1 old artifact(s)' journal lines were). Found by bin-venus-cc during VENUS-350 (msimxu8xce2c). Two defects in one: the glob crosses lanes, and the retention promise is silently unmet. Hold until VENUS-350 releases the file.
Activity
-
FIRST LIVE EVIDENCE, 2026-09-12 12:05 run, reported by coder-venus-cc and carried here by pmmaster's ruling. The prune ran for real for the first time: 1 encrypted artifact older than 7d removed from ~/.local/state/venus-db-backup and 1 from ~/gdrive/backup/venus, floor=3, leaving 86-1 in each lane. ZERO from /data-venus - both artifacts there are young, so prune_lane returns early and logs nothing. RE-DERIVE BEFORE ACTING. This row claims "retention 84 total not 84 encrypted, effective 6 days not 7". The observed population is 86 per lane, not 84, so the arithmetic in the row's original description was computed against a population that no longer holds. Whoever picks this up re-derives the effective-days figure against the measured lane sizes and the actual globs, which are venus-prod-*.sql.gz.gpg and *.sql.gz plus *.part at floor 0 (venus-db-backup.sh:708-709) - the two non-.gpg globs are exactly the cross-lane reach this row is about, and the floor applies per lane. TWO THINGS THE 12:05 RUN DID NOT SHOW, stated so its silence is not read as coverage. First, /data-venus was NOT exercised: prune_lane returned early and logged nothing, so the plain-rm-under-/data-venus path has still never run in production. An early return that logs nothing is indistinguishable from a path that ran and found nothing. Second, the floor was never approached - no ANOMALY line, because 86 is nowhere near 3 - so the floor-hit branch is also unexercised. SIBLING, NOT THIS ROW: the gdrive REMOTE holds 85 objects against the local lane's 86, so the remote has its own retention shape. coder-venus-cc filed that p3 separately. It is worth knowing here only because a naive reading of "86 vs 85" invites the conclusion that one object was lost, and nothing measured supports that. HELD under the fleet stop. This is evidence recorded on the row, not work started.
-
Duplicate of VENUS-358, fixed in venus-db-backup.sh v1.6 (2026-09-11) and still intact at v1.8. prune() calls prune_lane() once per lane with exact, non-prefix globs: 'venus-prod-*.sql.gz.gpg' (encrypted), 'venus-prod-*.sql.gz' (legacy plaintext, cannot match the .gpg lane because .gz has to be terminal) and 'venus-prod-*.part' (floor 0, age 0). v1.8 replaced the KEEP-count budget with age plus a per-lane floor, and the per-lane separation survived that rewrite unaltered - it was never about the number. Verified by reading lines 634-718 on 2026-09-18. Closing as duplicate, no new code.
bug
2026-08-07 by wi-cli-venus
4w ago
2026-09-18 06:22