Proposal: refresh HTTP cache on miss for exact-version restore (#3116)#14872
Open
Saibamen wants to merge 1 commit into
Open
Proposal: refresh HTTP cache on miss for exact-version restore (#3116)#14872Saibamen wants to merge 1 commit into
Saibamen wants to merge 1 commit into
Conversation
Adds a design proposal for resolving NuGet#3116, a long-standing inner-loop / CI failure where NuGet's cached versions list causes spurious NU1102 errors when a package is published and immediately consumed. The proposal describes a one-time, opt-out, refresh-on-miss heuristic in the V3 HTTP source stack: when a restore asks for an exact version that the cached versions list does not contain, refresh the cached document once before failing. Includes functional and technical explanation, drawbacks, alternatives considered, prior art (Cargo, npm, pip), and follow-ups. A companion implementation PR is open at NuGet/NuGet.Client#7321.
4 tasks
dotnet-policy-service
Bot
added
the
Community
nkolev92
reviewed
Apr 27, 2026
|
|
||
| ## Summary | ||
|
|
||
| When NuGet restore is asked to install a specific package version and the cached `index.json` (registration / versions list) for that package on a given V3 source does not contain the requested version, NuGet should treat the cache entry as potentially stale and transparently refresh it from the origin once before failing the restore. Today the cached document is reused for its full TTL (30 minutes by default), which causes spurious "package not found" failures for users who push and immediately consume packages from private feeds. This proposal adds a single, bounded, opportunistic refresh on a "version miss" so that the common case stays fast while the failing case becomes self-healing without users having to discover `--no-cache`, `RestoreNoCache`, or manual cache clearing. |
Member
There was a problem hiding this comment.
Thanks for this work @Saibamen.
A lot of the notes here are not really represented in the PR, so not really sure what to make of it.
I took a quick look and less than 0.3% of failed are restores are due to NU1102, while 5% of all projects have a calculated NU1603 (basically one where a restore actually happens and not relying on cached scenarios) which basically means the refreshing is more likely to affect many projects that may not need it.
There's definitely gotchas in those numbers, like where the data is collected, the assumption that all NU1102 errors would even be resolved by an extra refresh, but one thing is for sure that the impact of the extra work will be felt in many projects, even if they don't need it.
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
2 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.
Summary
Design proposal addressing #3116, the long-standing publish-then-consume failure where NuGet's cached versions list causes spurious
NU1102errors for up to 30 minutes after a package is published.The proposal introduces a one-time, opt-out, refresh-on-miss heuristic in the V3 HTTP source stack: when a restore asks for an exact version that the cached versions list does not contain, NuGet refreshes that one cached document from origin before failing.
(package id, source)per restore, on a path that was about to fail anyway.nuget.config, environment variable, or MSBuild property.Test plan
This is a design proposal, not code, so the "test plan" is review:
Companion implementation
A first implementation sketch (without the
nuget.config/ MSBuild knobs, env-var only) is open at NuGet/NuGet.Client#7321 so reviewers can see what the proposal looks like in code.