Repository navigation
test(cache): cover a remote cache entry expiring between fetch and download - #959
Merged
Merged
Conversation
…wnload `remote-cache-server expire-entry --before-download NUMBER` makes the tap expire the entry when its blob is next requested, before it forwards the request. The client requests the blob only after the fetch's response, so the entry always expires between the two, without sleeps. The `expired_after_fetch` case uses it: the fetch returns the entry, the download gets a 404, and the task reruns with the failed download as the miss reason. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fspy benchmarklinuxmacoswindows |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
A remote cache entry can expire after a fetch returns it but before its output archive is downloaded. The Worker then answers the download with
404 blob_missing. No case covered that race, and timing alone can't reproduce it without sleeps.remote-cache-server expire-entry --before-download NUMBERmakes the e2e backend's tap expire the entry when its blob is next requested, before it forwards the request. The client requests the blob only after the fetch's response, so the entry always expires between the two.The new
expired_after_fetchcase uses it. The fetch returnsexact [1],GET /blob/1gets a404, and the task reruns withremote cache download failedas the miss reason. That reason stays as it is: the fetch did find an entry that passed validation, and the same404also comes from a blob missing from the bucket while its entry is still live, which a plain "no previous cache entry found" would hide.🤖 Generated with Claude Code
Note
Low Risk
Changes are confined to e2e test harness and
remote-cache-servertooling; production remote-cache client behavior is unchanged.Overview
Adds e2e coverage for when a remote cache fetch succeeds but the blob download gets
404because the entry expired in between—a race that timing alone can't reproduce reliably.remote-cache-server expire-entry --before-download NUMBERmarks a blob so the test daemon's tap callsexpireEntryon the nextGET /blob/..., before forwarding—simulating retention expiring after the client has the fetch response but before it downloads the archive.The new
expired_after_fetchsnapshot case seeds a cache entry, arms that mode, then runsvt run buildagain after a localcache clean. It expectsPOST /fetch 200 exact [1],GET /blob/1 404, a rerun with miss reason remote cache download failed, and--last-detailsshowing the HTTP 404—not a plain "no entry" miss.Reviewed by Cursor Bugbot for commit ede3a69. Bugbot is set up for automated code reviews on this repo. Configure here.