What is wrong:downloadBlobToCache copies the blob with io.Copy in blobDiskCache.PutFromReader (internal/vaultik/restore.go, blobcache.go). The context is checked only between blobs, and the file:// backend's Get returns a file that ignores it. When one blob read outlasts the 30-second shutdown timeout, the process exits without the restore's cleanup. #159 required that the blob download into the cache stops on cancel; its fix checks only between blobs. With the default 10 GB blob_size_limit on a USB stick or a slow network share, one blob takes minutes.
How it was shown: one blob on the file:// destination replaced by a FIFO that delivers 1 MB and then stalls; snapshot restore; SIGINT after 4 s. vaultik exited 130 after 30 s, logging "Error during shutdown: context deadline exceeded", and left $TMPDIR/vaultik-restore-*/snapshot.db (plaintext) and $TMPDIR/vaultik-blobcache-*/HASH (decrypted file content). The warning that decrypted files may remain was not printed.
Definition of done
Cancelling a restore stops the blob read in progress, on every backend, so the cleanup runs before exit and removes the temporary database and cache.
The same holds for snapshot verify --deep, which reads blobs the same way.
A test covers cancelling during a stalled read.
Model: opus-5-5
Found by the defect hunt in https://git.eeqj.de/sneak/vaultik/issues/288 (part 3).
**What is wrong:** `downloadBlobToCache` copies the blob with `io.Copy` in `blobDiskCache.PutFromReader` (`internal/vaultik/restore.go`, `blobcache.go`). The context is checked only between blobs, and the `file://` backend's `Get` returns a file that ignores it. When one blob read outlasts the 30-second shutdown timeout, the process exits without the restore's cleanup. https://git.eeqj.de/sneak/vaultik/issues/159 required that the blob download into the cache stops on cancel; its fix checks only between blobs. With the default 10 GB `blob_size_limit` on a USB stick or a slow network share, one blob takes minutes.
**How it was shown:** one blob on the `file://` destination replaced by a FIFO that delivers 1 MB and then stalls; `snapshot restore`; SIGINT after 4 s. vaultik exited 130 after 30 s, logging "Error during shutdown: context deadline exceeded", and left `$TMPDIR/vaultik-restore-*/snapshot.db` (plaintext) and `$TMPDIR/vaultik-blobcache-*/HASH` (decrypted file content). The warning that decrypted files may remain was not printed.
**Definition of done**
- Cancelling a restore stops the blob read in progress, on every backend, so the cleanup runs before exit and removes the temporary database and cache.
- The same holds for `snapshot verify --deep`, which reads blobs the same way.
- A test covers cancelling during a stalled read.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 00:53:36 +02:00
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:
downloadBlobToCachecopies the blob withio.CopyinblobDiskCache.PutFromReader(internal/vaultik/restore.go,blobcache.go). The context is checked only between blobs, and thefile://backend'sGetreturns a file that ignores it. When one blob read outlasts the 30-second shutdown timeout, the process exits without the restore's cleanup. #159 required that the blob download into the cache stops on cancel; its fix checks only between blobs. With the default 10 GBblob_size_limiton a USB stick or a slow network share, one blob takes minutes.How it was shown: one blob on the
file://destination replaced by a FIFO that delivers 1 MB and then stalls;snapshot restore; SIGINT after 4 s. vaultik exited 130 after 30 s, logging "Error during shutdown: context deadline exceeded", and left$TMPDIR/vaultik-restore-*/snapshot.db(plaintext) and$TMPDIR/vaultik-blobcache-*/HASH(decrypted file content). The warning that decrypted files may remain was not printed.Definition of done
snapshot verify --deep, which reads blobs the same way.Model: opus-5-5