What was wrong:remote nuke deleted only what the snapshot listing and the blob listing recognise: snapshot directories holding a manifest.json.zst, and objects under blobs/ named by a blob hash. A snapshot's db.zst.age whose manifest was never uploaded, and a name such as blobs/0b/01/.DS_Store, survived while nuke printed that the store is empty and exited 0.
What changed: after removing every snapshot, as before, nuke lists everything under metadata/ and then blobs/ and deletes each object whatever its name, then the .partial files, then lists the prefix again. This replaces the blob prune step nuke used to run. A delete that fails is logged and the others still run. Nuke prints that the store is empty only when those listings find nothing; otherwise it names each object left in a warning and exits non-zero with the advice to run it again. The README entry for remote nuke says so. The existing test now also plants both kinds of leftover; a new test refuses one delete and checks that the object is named.
Judgement call: nuke no longer prints the blob prune summary ("Deleted N blob(s) totaling ...").
The final listing cannot see .partial files, which the file and rclone listings skip; a failure to delete one still fails the run.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/291.
**What was wrong:** `remote nuke` deleted only what the snapshot listing and the blob listing recognise: snapshot directories holding a `manifest.json.zst`, and objects under `blobs/` named by a blob hash. A snapshot's `db.zst.age` whose manifest was never uploaded, and a name such as `blobs/0b/01/.DS_Store`, survived while nuke printed that the store is empty and exited 0.
**What changed:** after removing every snapshot, as before, nuke lists everything under `metadata/` and then `blobs/` and deletes each object whatever its name, then the `.partial` files, then lists the prefix again. This replaces the blob prune step nuke used to run. A delete that fails is logged and the others still run. Nuke prints that the store is empty only when those listings find nothing; otherwise it names each object left in a warning and exits non-zero with the advice to run it again. The README entry for `remote nuke` says so. The existing test now also plants both kinds of leftover; a new test refuses one delete and checks that the object is named.
- Judgement call: nuke no longer prints the blob prune summary ("Deleted N blob(s) totaling ...").
- The final listing cannot see `.partial` files, which the file and rclone listings skip; a failure to delete one still fails the run.
Model: opus-5-5
remote nuke deleted only the snapshot metadata and blobs the snapshot
and blob listings recognise, so a snapshot's database whose manifest
was never uploaded, and any name under blobs/ that is not a blob hash,
survived while nuke reported the store empty.
After removing every snapshot, nuke now deletes every object listed
under metadata/ and blobs/, whatever its name, in place of the blob
prune step. A delete that fails is logged and the others still run. A
listing afterwards decides the result: nuke reports the store empty
only when it finds nothing, and otherwise names each object left and
fails.
Judgement call: nuke no longer prints the blob prune summary.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #291.
What was wrong:
remote nukedeleted only what the snapshot listing and the blob listing recognise: snapshot directories holding amanifest.json.zst, and objects underblobs/named by a blob hash. A snapshot'sdb.zst.agewhose manifest was never uploaded, and a name such asblobs/0b/01/.DS_Store, survived while nuke printed that the store is empty and exited 0.What changed: after removing every snapshot, as before, nuke lists everything under
metadata/and thenblobs/and deletes each object whatever its name, then the.partialfiles, then lists the prefix again. This replaces the blob prune step nuke used to run. A delete that fails is logged and the others still run. Nuke prints that the store is empty only when those listings find nothing; otherwise it names each object left in a warning and exits non-zero with the advice to run it again. The README entry forremote nukesays so. The existing test now also plants both kinds of leftover; a new test refuses one delete and checks that the object is named..partialfiles, which the file and rclone listings skip; a failure to delete one still fails the run.Model: opus-5-5
Review passed.
Model: opus-5-5