fix: stale refs after snapshot restore and server restart#180
Merged
Conversation
Two codepaths could serve stale git refs: 1. After snapshot restore: MarkRestored() set the repo to StateReady immediately, but the catch-up fetch was only scheduled asynchronously. First clients would get stale refs from the snapshot. 2. After server restart with existing repos on disk: DiscoverExisting() set repos to StateReady with no fetch at all. Repos sat stale until the first request triggered an async maybeBackgroundFetch. Fix both by running a synchronous fetch before the repo starts serving: - In startClone: fetch synchronously after snapshot restore instead of scheduling an async backgroundFetch - In strategy init: fetch each discovered repo at startup before accepting requests Added diagnostic logging of ref SHAs before and after each fetch to aid debugging. Co-authored-by: Claude Code <noreply@anthropic.com> Ai-assisted: true
| slog.String("error", err.Error())) | ||
| } | ||
| for _, repo := range existing { | ||
| logger.InfoContext(ctx, "Running startup fetch for existing repo", |
Contributor
There was a problem hiding this comment.
any idea what impact this'll have on startup times for cachew?
(they already seem to be really long from what I can see)
Contributor
Author
There was a problem hiding this comment.
Frankly I don't know, but I think it's critical to have this functionality (open to different implementation) as currently we would be (or actually are) just serving a stale content.
| slog.String("error", err.Error()), | ||
| slog.Duration("duration", time.Since(start))) | ||
| } else { | ||
| logger.InfoContext(ctx, "Startup fetch completed for existing repo", |
Contributor
There was a problem hiding this comment.
I'm wondering if the Info logging will be a bit too verbose for the happy case paths.
Contributor
Author
There was a problem hiding this comment.
Having it was actually very helpful in discovering that there are two different code paths here. Given that this is not used much, and this logging was and might be very helpful I'm inclined to keep it till it becomes too annoying (once cachew is stable and widely adopted).
jrobotham-square
approved these changes
Mar 12, 2026
alecthomas
changed the title
alecthomas
reviewed
Mar 12, 2026
| slog.String("upstream", repo.UpstreamURL()), | ||
| slog.String("error", err.Error())) | ||
| } else { | ||
| logger.InfoContext(ctx, "Post-fetch refs for existing repo", |
Collaborator
There was a problem hiding this comment.
This definitely shouldn't be at info
worstell
pushed a commit
that referenced
this pull request
Mar 12, 2026
Two codepaths could serve stale git refs: 1. After snapshot restore: MarkRestored() set the repo to StateReady immediately, but the catch-up fetch was only scheduled asynchronously. First clients would get stale refs from the snapshot. 2. After server restart with existing repos on disk: DiscoverExisting() set repos to StateReady with no fetch at all. Repos sat stale until the first request triggered an async maybeBackgroundFetch. Fix both by running a synchronous fetch before the repo starts serving: - In startClone: fetch synchronously after snapshot restore instead of scheduling an async backgroundFetch - In strategy init: fetch each discovered repo at startup before accepting requests Added diagnostic logging of ref SHAs before and after each fetch to aid debugging. Co-authored-by: Claude Code <noreply@anthropic.com>
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
3 participants
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.
Two codepaths could serve stale git refs:
After snapshot restore: MarkRestored() set the repo to StateReady immediately, but the catch-up fetch was only scheduled asynchronously. First clients would get stale refs from the snapshot.
After server restart with existing repos on disk: DiscoverExisting() set repos to StateReady with no fetch at all. Repos sat stale until the first request triggered an async maybeBackgroundFetch.
Fix both by running a synchronous fetch before the repo starts serving:
Added diagnostic logging of ref SHAs before and after each fetch to aid debugging.