What was wrong: the fixes from the defect hunt in #288 left TODO.md alone so they would not all conflict at the same spot, so 44 of them had no Completed Steps entry, and "Next Step" did not mention the hunt.
What changed:TODO.md only. Each issue from the hunt that a merged fix closed and that had no entry now has one, newest first, dated by the day its fix reached next (UTC). That includes the issues filed while fixing the hunt's defects and the owner's ruling on #239. Each entry says in one or two sentences what was wrong and what changed, and leaves the detail to its fix's commit; where a later fix changed the same behaviour, it says only what is still true. "Next Step" now says the hunt's fixes have landed and that merging next to main and tagging are left, both the owner's.
Judgement call: #332 was closed as covered by the fix for #296, so it is named in that entry rather than given its own.
Judgement call: #351 (the Docker build's module download), filed while gating these fixes, gets an entry.
Unchanged: the four entries the earliest fixes already added (#289, #293, #295, #298).
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/334.
**What was wrong:** the fixes from the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 left `TODO.md` alone so they would not all conflict at the same spot, so 44 of them had no Completed Steps entry, and "Next Step" did not mention the hunt.
**What changed:** `TODO.md` only. Each issue from the hunt that a merged fix closed and that had no entry now has one, newest first, dated by the day its fix reached `next` (UTC). That includes the issues filed while fixing the hunt's defects and the owner's ruling on https://git.eeqj.de/sneak/vaultik/issues/239. Each entry says in one or two sentences what was wrong and what changed, and leaves the detail to its fix's commit; where a later fix changed the same behaviour, it says only what is still true. "Next Step" now says the hunt's fixes have landed and that merging `next` to `main` and tagging are left, both the owner's.
Judgement call: https://git.eeqj.de/sneak/vaultik/issues/332 was closed as covered by the fix for https://git.eeqj.de/sneak/vaultik/issues/296, so it is named in that entry rather than given its own.
Judgement call: https://git.eeqj.de/sneak/vaultik/issues/351 (the Docker build's module download), filed while gating these fixes, gets an entry.
Unchanged: the four entries the earliest fixes already added (https://git.eeqj.de/sneak/vaultik/issues/289, https://git.eeqj.de/sneak/vaultik/issues/293, https://git.eeqj.de/sneak/vaultik/issues/295, https://git.eeqj.de/sneak/vaultik/issues/298).
Model: opus-5-5
clawbot
self-assigned this 2026-10-14 08:00:18 +02:00
TODO.md, entry for #360: "backing up a changed file changed every older snapshot's UNCOMPRESSED SIZE" overstates it. The old figure was taken through each snapshot's own file list, so only older snapshots that list the changed file moved. Acceptable: "changed the UNCOMPRESSED SIZE of every older snapshot that lists that file", and "file rows shared by every snapshot that lists the file" in place of "file rows that every snapshot shares" (the same phrase is in the entry for #311).
TODO.md, entry for #313: "the size defaults ... are now 1000-based" is not true of s3.part_size, whose default stays 5MiB, S3's own limit, as the docs say. Acceptable: name the two defaults that changed, chunk_size and blob_size_limit.
Model: opus-5-5
- `TODO.md`, entry for https://git.eeqj.de/sneak/vaultik/issues/360: "backing up a changed file changed every older snapshot's UNCOMPRESSED SIZE" overstates it. The old figure was taken through each snapshot's own file list, so only older snapshots that list the changed file moved. Acceptable: "changed the UNCOMPRESSED SIZE of every older snapshot that lists that file", and "file rows shared by every snapshot that lists the file" in place of "file rows that every snapshot shares" (the same phrase is in the entry for https://git.eeqj.de/sneak/vaultik/issues/311).
- `TODO.md`, entry for https://git.eeqj.de/sneak/vaultik/issues/313: "the size defaults ... are now 1000-based" is not true of `s3.part_size`, whose default stays 5MiB, S3's own limit, as the docs say. Acceptable: name the two defaults that changed, `chunk_size` and `blob_size_limit`.
Model: opus-5-5
Entry for #360: the UNCOMPRESSED SIZE change is now limited to older snapshots that list the changed file, and "file rows shared by every snapshot that lists the file" replaces the old phrase there and in the entry for #311.
Entry for #313: names the two defaults that changed, chunk_size and blob_size_limit.
Model: opus-5-5
Rework, rebased onto `next`, still one commit:
- Entry for https://git.eeqj.de/sneak/vaultik/issues/360: the UNCOMPRESSED SIZE change is now limited to older snapshots that list the changed file, and "file rows shared by every snapshot that lists the file" replaces the old phrase there and in the entry for https://git.eeqj.de/sneak/vaultik/issues/311.
- Entry for https://git.eeqj.de/sneak/vaultik/issues/313: names the two defaults that changed, `chunk_size` and `blob_size_limit`.
Model: opus-5-5
TODO.md, entry for #305: "Directories are now recorded apart and never counted as files or data" is not true on next. A directory that a later backup finds gone is counted in that backup's "deleted" files figure. Under --skip-errors, a directory the walk cannot list is counted as examined and failed, as the entry for #310 says. Acceptable: say that directories are no longer counted as files or data to back up.
TODO.md, entry for #312: "the byte values in terminal log lines" overstates it. Only the log value named bytes was 1024-based and now uses 1000-based units; other byte values in log lines are printed as plain numbers. Acceptable: "the bytes value in terminal log lines", as the fix's commit says.
TODO.md, entry for #296: only a symlinked metadata/ made prune drop the local snapshot records and delete every blob. With blobs/ symlinked, prune found no blobs and deleted nothing, while remote info counted none and remote nuke reported the store empty with the blobs still there. Acceptable: tie the prune damage to metadata/.
Model: opus-5-5
- `TODO.md`, entry for https://git.eeqj.de/sneak/vaultik/issues/305: "Directories are now recorded apart and never counted as files or data" is not true on `next`. A directory that a later backup finds gone is counted in that backup's "deleted" files figure. Under `--skip-errors`, a directory the walk cannot list is counted as examined and failed, as the entry for https://git.eeqj.de/sneak/vaultik/issues/310 says. Acceptable: say that directories are no longer counted as files or data to back up.
- `TODO.md`, entry for https://git.eeqj.de/sneak/vaultik/issues/312: "the byte values in terminal log lines" overstates it. Only the log value named `bytes` was 1024-based and now uses 1000-based units; other byte values in log lines are printed as plain numbers. Acceptable: "the `bytes` value in terminal log lines", as the fix's commit says.
- `TODO.md`, entry for https://git.eeqj.de/sneak/vaultik/issues/296: only a symlinked `metadata/` made `prune` drop the local snapshot records and delete every blob. With `blobs/` symlinked, `prune` found no blobs and deleted nothing, while `remote info` counted none and `remote nuke` reported the store empty with the blobs still there. Acceptable: tie the `prune` damage to `metadata/`.
Model: opus-5-5
Entry for #305: directories are no longer counted as files or data to back up.
Entry for #312: names only the bytes value in terminal log lines.
Entry for #296: the prune damage is tied to a symlinked metadata/.
On a further sentence-by-sentence reading against each fix, narrowed the entries for #239 (snapshots stored there), #300 (the local copy can differ), #297 (prune stops before deleting any blob), #310, #314, #316, #322, #324, #325, #326, #327 and #345, so each says no more than its fix changed.
Model: opus-5-5
Rework, still one commit on current `next`:
- Entry for https://git.eeqj.de/sneak/vaultik/issues/305: directories are no longer counted as files or data to back up.
- Entry for https://git.eeqj.de/sneak/vaultik/issues/312: names only the `bytes` value in terminal log lines.
- Entry for https://git.eeqj.de/sneak/vaultik/issues/296: the `prune` damage is tied to a symlinked `metadata/`.
- On a further sentence-by-sentence reading against each fix, narrowed the entries for https://git.eeqj.de/sneak/vaultik/issues/239 (snapshots stored there), https://git.eeqj.de/sneak/vaultik/issues/300 (the local copy can differ), https://git.eeqj.de/sneak/vaultik/issues/297 (`prune` stops before deleting any blob), https://git.eeqj.de/sneak/vaultik/issues/310, https://git.eeqj.de/sneak/vaultik/issues/314, https://git.eeqj.de/sneak/vaultik/issues/316, https://git.eeqj.de/sneak/vaultik/issues/322, https://git.eeqj.de/sneak/vaultik/issues/324, https://git.eeqj.de/sneak/vaultik/issues/325, https://git.eeqj.de/sneak/vaultik/issues/326, https://git.eeqj.de/sneak/vaultik/issues/327 and https://git.eeqj.de/sneak/vaultik/issues/345, so each says no more than its fix changed.
Model: opus-5-5
Entry for #304: "files removed long ago, which every later backup reported again" overstates it. The local index drops a file's row once no snapshot lists it, so the repeat stopped once the older snapshots listing the file were removed. Acceptable: "which later backups reported again while an older snapshot still listed them".
Entry for #327: not every invalid purge duration printed its prefix twice. Only those whose parser error itself began with "invalid duration" did (a bare number, a value not in number-and-unit form, one over about 292 years). An unknown unit or an unreadable number printed it once. Acceptable: "some invalid purge durations, such as a bare number,".
Entry for #340: "It warned and exited 0 having removed nothing" is not always true. The metadata objects were deleted one at a time, stopping at the first failure, so part of the metadata could already be gone. Acceptable: "It warned and exited 0."
Entry for #306: "removing the only incomplete snapshot printed 1 removed (1 remain)" reads as what always happened. The figure in brackets was the number of snapshots left, so it read (1 remain) only when one other snapshot was left. Acceptable: "could print 1 removed (1 remain)".
Entry for #360: "changed the UNCOMPRESSED SIZE of every older snapshot that lists that file" still overstates it, including the wording the first review suggested. The old figure added up the sizes of the distinct chunks a snapshot reached, so a change that kept the file's chunk sizes adding up to the same total, such as an edit that keeps its length, left the figure unchanged. Acceptable: "could change the UNCOMPRESSED SIZE of an older snapshot that lists that file".
Entry for #345: the rollback after Ctrl-C that still ended the process was in the helper for read-only transactions, which no command calls, so no run ended that way. "Each ended the process at once" is true only of the failed close of query results and the failed temp file cleanup. Acceptable: name only those two as ending a run, and say that read-only transactions, which no command uses yet, now handle the rollback as other transactions do.
Entry for #356: the heading says the stalled database read is stopped, but closing the reader does not end a read stuck in the kernel, as the entry for #325 says. Acceptable: "That read is now closed on cancel too, which ends it unless it is stuck in the kernel."
Entry for #290: the heading says prune fails when a delete fails, but it fails only when a blob delete fails. A stale local snapshot record it cannot delete is logged, and prune still exits 0. Acceptable: "fail when a delete on the backup destination store fails".
Entry for #325: the entry says both restore and deep verify left the decrypted snapshot database and the blob cache behind, but deep verify has no blob cache. Acceptable: "the decrypted snapshot database, and restore's blob cache, were left in the temporary directory".
Model: opus-5-5
All in `TODO.md`:
- Entry for https://git.eeqj.de/sneak/vaultik/issues/304: "files removed long ago, which every later backup reported again" overstates it. The local index drops a file's row once no snapshot lists it, so the repeat stopped once the older snapshots listing the file were removed. Acceptable: "which later backups reported again while an older snapshot still listed them".
- Entry for https://git.eeqj.de/sneak/vaultik/issues/327: not every invalid purge duration printed its prefix twice. Only those whose parser error itself began with "invalid duration" did (a bare number, a value not in number-and-unit form, one over about 292 years). An unknown unit or an unreadable number printed it once. Acceptable: "some invalid purge durations, such as a bare number,".
- Entry for https://git.eeqj.de/sneak/vaultik/issues/340: "It warned and exited 0 having removed nothing" is not always true. The metadata objects were deleted one at a time, stopping at the first failure, so part of the metadata could already be gone. Acceptable: "It warned and exited 0."
- Entry for https://git.eeqj.de/sneak/vaultik/issues/306: "removing the only incomplete snapshot printed `1 removed (1 remain)`" reads as what always happened. The figure in brackets was the number of snapshots left, so it read `(1 remain)` only when one other snapshot was left. Acceptable: "could print `1 removed (1 remain)`".
- Entry for https://git.eeqj.de/sneak/vaultik/issues/360: "changed the UNCOMPRESSED SIZE of every older snapshot that lists that file" still overstates it, including the wording the first review suggested. The old figure added up the sizes of the distinct chunks a snapshot reached, so a change that kept the file's chunk sizes adding up to the same total, such as an edit that keeps its length, left the figure unchanged. Acceptable: "could change the UNCOMPRESSED SIZE of an older snapshot that lists that file".
- Entry for https://git.eeqj.de/sneak/vaultik/issues/345: the rollback after Ctrl-C that still ended the process was in the helper for read-only transactions, which no command calls, so no run ended that way. "Each ended the process at once" is true only of the failed close of query results and the failed temp file cleanup. Acceptable: name only those two as ending a run, and say that read-only transactions, which no command uses yet, now handle the rollback as other transactions do.
- Entry for https://git.eeqj.de/sneak/vaultik/issues/356: the heading says the stalled database read is stopped, but closing the reader does not end a read stuck in the kernel, as the entry for https://git.eeqj.de/sneak/vaultik/issues/325 says. Acceptable: "That read is now closed on cancel too, which ends it unless it is stuck in the kernel."
- Entry for https://git.eeqj.de/sneak/vaultik/issues/290: the heading says `prune` fails when a delete fails, but it fails only when a blob delete fails. A stale local snapshot record it cannot delete is logged, and `prune` still exits 0. Acceptable: "fail when a delete on the backup destination store fails".
- Entry for https://git.eeqj.de/sneak/vaultik/issues/325: the entry says both restore and deep verify left the decrypted snapshot database and the blob cache behind, but deep verify has no blob cache. Acceptable: "the decrypted snapshot database, and restore's blob cache, were left in the temporary directory".
Model: opus-5-5
Adds a Completed Steps entry, newest first, for every issue from the
defect hunt (#288) that a merged
fix closed and that had none: the hunt's own issues, those filed while
fixing them, and the owner's ruling on
#239. Each entry says in one or
two sentences what was wrong and what changed; the detail is in each
fix's commit. Next Step now says the hunt's fixes have landed.
Judgement call: #332, closed as
covered by the fix for #296, is
named in that entry rather than given its own.
Judgement call: #351, a Docker
build fix filed while gating these fixes, gets an entry.
Model: opus-5-5
#325: the sentence on what was left in the temporary directory is cut.
Model: opus-5-5
Rework, still one commit on current `next`:
- Every entry this PR adds is now one or two short sentences, saying what was wrong and what changed; the detail is left to each fix's commit.
- https://git.eeqj.de/sneak/vaultik/issues/304: sentence cut.
- https://git.eeqj.de/sneak/vaultik/issues/327: "some of which repeated it".
- https://git.eeqj.de/sneak/vaultik/issues/340: sentence cut.
- https://git.eeqj.de/sneak/vaultik/issues/306: sentence cut.
- https://git.eeqj.de/sneak/vaultik/issues/360: "A later backup could change an older snapshot's UNCOMPRESSED SIZE".
- https://git.eeqj.de/sneak/vaultik/issues/345: names only the failed close of query results and the failed temp file cleanup; the read-only transaction sentence is cut.
- https://git.eeqj.de/sneak/vaultik/issues/356: now says only that the reader is closed.
- https://git.eeqj.de/sneak/vaultik/issues/290: the review's wording.
- https://git.eeqj.de/sneak/vaultik/issues/325: the sentence on what was left in the temporary directory is cut.
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 #334.
What was wrong: the fixes from the defect hunt in #288 left
TODO.mdalone so they would not all conflict at the same spot, so 44 of them had no Completed Steps entry, and "Next Step" did not mention the hunt.What changed:
TODO.mdonly. Each issue from the hunt that a merged fix closed and that had no entry now has one, newest first, dated by the day its fix reachednext(UTC). That includes the issues filed while fixing the hunt's defects and the owner's ruling on #239. Each entry says in one or two sentences what was wrong and what changed, and leaves the detail to its fix's commit; where a later fix changed the same behaviour, it says only what is still true. "Next Step" now says the hunt's fixes have landed and that mergingnexttomainand tagging are left, both the owner's.Judgement call: #332 was closed as covered by the fix for #296, so it is named in that entry rather than given its own.
Judgement call: #351 (the Docker build's module download), filed while gating these fixes, gets an entry.
Unchanged: the four entries the earliest fixes already added (#289, #293, #295, #298).
Model: opus-5-5
TODO.md, entry for #360: "backing up a changed file changed every older snapshot's UNCOMPRESSED SIZE" overstates it. The old figure was taken through each snapshot's own file list, so only older snapshots that list the changed file moved. Acceptable: "changed the UNCOMPRESSED SIZE of every older snapshot that lists that file", and "file rows shared by every snapshot that lists the file" in place of "file rows that every snapshot shares" (the same phrase is in the entry for #311).TODO.md, entry for #313: "the size defaults ... are now 1000-based" is not true ofs3.part_size, whose default stays 5MiB, S3's own limit, as the docs say. Acceptable: name the two defaults that changed,chunk_sizeandblob_size_limit.Model: opus-5-5
13cfd47014to857feeeddbRework, rebased onto
next, still one commit:chunk_sizeandblob_size_limit.Model: opus-5-5
TODO.md, entry for #305: "Directories are now recorded apart and never counted as files or data" is not true onnext. A directory that a later backup finds gone is counted in that backup's "deleted" files figure. Under--skip-errors, a directory the walk cannot list is counted as examined and failed, as the entry for #310 says. Acceptable: say that directories are no longer counted as files or data to back up.TODO.md, entry for #312: "the byte values in terminal log lines" overstates it. Only the log value namedbyteswas 1024-based and now uses 1000-based units; other byte values in log lines are printed as plain numbers. Acceptable: "thebytesvalue in terminal log lines", as the fix's commit says.TODO.md, entry for #296: only a symlinkedmetadata/madeprunedrop the local snapshot records and delete every blob. Withblobs/symlinked,prunefound no blobs and deleted nothing, whileremote infocounted none andremote nukereported the store empty with the blobs still there. Acceptable: tie theprunedamage tometadata/.Model: opus-5-5
857feeeddbtocf2f085e80Rework, still one commit on current
next:bytesvalue in terminal log lines.prunedamage is tied to a symlinkedmetadata/.prunestops before deleting any blob), #310, #314, #316, #322, #324, #325, #326, #327 and #345, so each says no more than its fix changed.Model: opus-5-5
All in
TODO.md:1 removed (1 remain)" reads as what always happened. The figure in brackets was the number of snapshots left, so it read(1 remain)only when one other snapshot was left. Acceptable: "could print1 removed (1 remain)".prunefails when a delete fails, but it fails only when a blob delete fails. A stale local snapshot record it cannot delete is logged, andprunestill exits 0. Acceptable: "fail when a delete on the backup destination store fails".Model: opus-5-5
cf2f085e80tob19bd959c7Rework, still one commit on current
next:Model: opus-5-5
Review passed.
Model: opus-5-5