Restore and snapshot verify --deep looked for a cancel only between blobs, and the reader the file backend returns for a blob ignores the context. When one blob read stalled (a slow USB stick or network share), an interrupt waited on it past the 30-second shutdown timeout, and the process exited without removing the decrypted snapshot database and blob cache from the temp directory.
FetchBlob, through which both commands read every blob, now wraps the storage reader so it is closed as soon as the context is cancelled. Closing ends the blocked read on any backend, so the command unwinds and its cleanup runs. After a cancel, a read returns the context's error rather than the closed reader's, so an interrupted restore still returns context.Canceled.
The new test stops a restore and a deep verify while a blob read is stalled on a reader that ignores the context, and checks that stopping returns promptly and leaves no decrypted files in the temp directory.
Limitation: a read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) still cannot be stopped; a slow read that keeps delivering data stops after its current read.
Partly verified: the test stands in for the stalled source with an in-memory pipe; the issue's FIFO on a real file:// destination was not re-run with the built binary.
Judgement call: only blob reads are covered, as the issue asks; downloads of the snapshot database and manifests still use readers that ignore the context.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/vaultik/issues/325.
Restore and `snapshot verify --deep` looked for a cancel only between blobs, and the reader the file backend returns for a blob ignores the context. When one blob read stalled (a slow USB stick or network share), an interrupt waited on it past the 30-second shutdown timeout, and the process exited without removing the decrypted snapshot database and blob cache from the temp directory.
`FetchBlob`, through which both commands read every blob, now wraps the storage reader so it is closed as soon as the context is cancelled. Closing ends the blocked read on any backend, so the command unwinds and its cleanup runs. After a cancel, a read returns the context's error rather than the closed reader's, so an interrupted restore still returns `context.Canceled`.
The new test stops a restore and a deep verify while a blob read is stalled on a reader that ignores the context, and checks that stopping returns promptly and leaves no decrypted files in the temp directory.
- Limitation: a read stuck in the kernel that closing cannot interrupt (an unresponsive hard NFS mount) still cannot be stopped; a slow read that keeps delivering data stops after its current read.
- Partly verified: the test stands in for the stalled source with an in-memory pipe; the issue's FIFO on a real `file://` destination was not re-run with the built binary.
- Judgement call: only blob reads are covered, as the issue asks; downloads of the snapshot database and manifests still use readers that ignore the context.
Model: opus-5-5
Restore and deep verify looked for a cancel only between blobs, and the
file backend's reader ignores the context. A blob read stalled on a
slow USB stick or network share outlasted the 30-second shutdown
timeout, so the process exited before removing the decrypted snapshot
database and blob cache from the temp directory.
FetchBlob, through which both read every blob, now closes the storage
reader as soon as the context is cancelled, ending a blocked read on
any backend; Read then returns the context's error, not the closed
reader's.
Limitation: a read stuck in the kernel that closing cannot interrupt,
such as one on an unresponsive hard NFS mount, still cannot be stopped.
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 #325.
Restore and
snapshot verify --deeplooked for a cancel only between blobs, and the reader the file backend returns for a blob ignores the context. When one blob read stalled (a slow USB stick or network share), an interrupt waited on it past the 30-second shutdown timeout, and the process exited without removing the decrypted snapshot database and blob cache from the temp directory.FetchBlob, through which both commands read every blob, now wraps the storage reader so it is closed as soon as the context is cancelled. Closing ends the blocked read on any backend, so the command unwinds and its cleanup runs. After a cancel, a read returns the context's error rather than the closed reader's, so an interrupted restore still returnscontext.Canceled.The new test stops a restore and a deep verify while a blob read is stalled on a reader that ignores the context, and checks that stopping returns promptly and leaves no decrypted files in the temp directory.
file://destination was not re-run with the built binary.Model: opus-5-5
Review passed.
Model: opus-5-5