What is wrong:#325 makes a cancel stop a stalled blob read so the cleanup runs. The snapshot database is read through a different path, downloadSnapshotDB (internal/vaultik/restore.go) and downloadVerifiedSnapshotDB (internal/vaultik/verify.go), which still ignores the cancel: when that read stalls (a slow USB stick or network share) and the user presses Ctrl-C, the process exits after the shutdown timeout without the cleanup and leaves the decrypted database in the temp directory.
Definition of done
Interrupting snapshot restore or snapshot verify --deep while the snapshot database is being read stops that read, on every backend, so the cleanup runs and no decrypted file remains in the temp directory.
A test covers a stalled snapshot-database read for each command, in the style of the test for #325.
Model: opus-5-5
Found while fixing https://git.eeqj.de/sneak/vaultik/issues/325.
**What is wrong:** https://git.eeqj.de/sneak/vaultik/issues/325 makes a cancel stop a stalled blob read so the cleanup runs. The snapshot database is read through a different path, `downloadSnapshotDB` (`internal/vaultik/restore.go`) and `downloadVerifiedSnapshotDB` (`internal/vaultik/verify.go`), which still ignores the cancel: when that read stalls (a slow USB stick or network share) and the user presses Ctrl-C, the process exits after the shutdown timeout without the cleanup and leaves the decrypted database in the temp directory.
**Definition of done**
- Interrupting `snapshot restore` or `snapshot verify --deep` while the snapshot database is being read stops that read, on every backend, so the cleanup runs and no decrypted file remains in the temp directory.
- A test covers a stalled snapshot-database read for each command, in the style of the test for https://git.eeqj.de/sneak/vaultik/issues/325.
Model: opus-5-5
clawbot
self-assigned this 2026-10-13 13:20:18 +02:00
Built in #363: the snapshot database read in restore and deep verify now has its storage reader closed as soon as the command is interrupted, the same way blob reads are, so a stalled read ends and the decrypted temporary database is removed before exit. A read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) is still not stoppable.
Model: opus-5-5
Built in https://git.eeqj.de/sneak/vaultik/pulls/363: the snapshot database read in restore and deep verify now has its storage reader closed as soon as the command is interrupted, the same way blob reads are, so a stalled read ends and the decrypted temporary database is removed before exit. A read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) is still not stoppable.
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 while fixing #325.
What is wrong: #325 makes a cancel stop a stalled blob read so the cleanup runs. The snapshot database is read through a different path,
downloadSnapshotDB(internal/vaultik/restore.go) anddownloadVerifiedSnapshotDB(internal/vaultik/verify.go), which still ignores the cancel: when that read stalls (a slow USB stick or network share) and the user presses Ctrl-C, the process exits after the shutdown timeout without the cleanup and leaves the decrypted database in the temp directory.Definition of done
snapshot restoreorsnapshot verify --deepwhile the snapshot database is being read stops that read, on every backend, so the cleanup runs and no decrypted file remains in the temp directory.Model: opus-5-5
Built in #363: the snapshot database read in restore and deep verify now has its storage reader closed as soon as the command is interrupted, the same way blob reads are, so a stalled read ends and the decrypted temporary database is removed before exit. A read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) is still not stoppable.
Model: opus-5-5