What is wrong:restoreSweeper.blobStillNeeded (internal/vaultik/restore_sweeper.go) keeps a cached blob while any file in the snapshot database that uses one of its chunks is not in the restored set. Files outside the selection, and files that failed under --skip-errors, never enter that set, so such a blob is never freed. Each cache entry is a whole decrypted blob in $TMPDIR (up to blob_size_limit, 10 GB by default), so the temporary space grows with the number of blobs touched instead of staying near one blob.
How it was shown: a throwaway test on the TestRestoreLocalityAndReadAt fixture (3 blobs), restoring by path every src-*.bin except two: the cache peaked at 3 entries; the same restore without paths peaks at 1.
Definition of done
A cached blob is freed once no file still to be restored in this run needs it, whether or not paths were given and whether or not some files failed.
A test covers a restore by path and one with a failed file.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 3).
**What is wrong:** `restoreSweeper.blobStillNeeded` (`internal/vaultik/restore_sweeper.go`) keeps a cached blob while any file in the snapshot database that uses one of its chunks is not in the restored set. Files outside the selection, and files that failed under `--skip-errors`, never enter that set, so such a blob is never freed. Each cache entry is a whole decrypted blob in `$TMPDIR` (up to `blob_size_limit`, 10 GB by default), so the temporary space grows with the number of blobs touched instead of staying near one blob.
**How it was shown:** a throwaway test on the `TestRestoreLocalityAndReadAt` fixture (3 blobs), restoring by path every `src-*.bin` except two: the cache peaked at 3 entries; the same restore without paths peaks at 1.
**Definition of done**
- A cached blob is freed once no file still to be restored in this run needs it, whether or not paths were given and whether or not some files failed.
- A test covers a restore by path and one with a failed file.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:53:36 +02:00
Implemented in #372. The sweeper now asks the restore plan, which holds only the files this run still has to restore, whether a cached blob is still needed, so files outside the requested paths and files that failed no longer keep blobs.
Model: opus-5-5
Implemented in https://git.eeqj.de/sneak/vaultik/pulls/372. The sweeper now asks the restore plan, which holds only the files this run still has to restore, whether a cached blob is still needed, so files outside the requested paths and files that failed no longer keep blobs.
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.
Found by the defect hunt in #288 (part 3).
What is wrong:
restoreSweeper.blobStillNeeded(internal/vaultik/restore_sweeper.go) keeps a cached blob while any file in the snapshot database that uses one of its chunks is not in the restored set. Files outside the selection, and files that failed under--skip-errors, never enter that set, so such a blob is never freed. Each cache entry is a whole decrypted blob in$TMPDIR(up toblob_size_limit, 10 GB by default), so the temporary space grows with the number of blobs touched instead of staying near one blob.How it was shown: a throwaway test on the
TestRestoreLocalityAndReadAtfixture (3 blobs), restoring by path everysrc-*.binexcept two: the cache peaked at 3 entries; the same restore without paths peaks at 1.Definition of done
Model: opus-5-5
Implemented in #372. The sweeper now asks the restore plan, which holds only the files this run still has to restore, whether a cached blob is still needed, so files outside the requested paths and files that failed no longer keep blobs.
Model: opus-5-5