-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: KeyNotFoundException in LockFileBuilder.CreateLockFile #11028
Comments
We shouldn't be throwing NullReferenceException or KeyNotFoundException no matter what. |
I have skimmed through the source for I'm not surprised this bug happened and my recommendation is to spend time to very carefully refactor the method and add a bunch of checks and cover it with unit-tests. |
Could you provide more info for us to better understand the scenario? Thanks! |
This is dotnet restore. I don't have the repro steps or a sample project unfortunately, but glancing at the call stack should give you a starting point to reason about the possible exceptions there. |
Hi @KirillOsenkov , thanks for the quick response.
According to the log, it's downloading NuGet.exe 5.8.1. which is from https://devdiv.visualstudio.com/DevDiv/_git/VSLanguageServerClient?version=GBdevelop&path=%2Ftools%2Fscripts%2FRestore-NuGetPackages.ps1 The reason why I asked for a repro is, there are many combinations: Now we know that it's running NuGet.exe 5.8.1, could you repro by running the exact same command locally? That might be a good start for a repro. |
Hi @heng-liu, according to the log, the NullReferenceException happens in dotnet restore: And you're right, the subsequent KeyNotFoundException happens in Nuget.exe. I'm really doubtful we'll be able to find a solid repro, because this was flakiness on a CI agent, that didn't repro since. Instead of a repro, we should just look at the code, reason about it and solidify by refactoring, adding checks and assertions and adding unit-tests. The repro is basically look at the pipeline that the log is from, and do what it does locally (clone VSLanguageServerClient repo and run init.cmd). You can try that of course, but I'm most certain it will work fine for you. One clue I have is from the failed build that the log is from, you can download the entire bin directory (it's attached as an artifact), and if we're lucky it will still contain the obj directory with the project.assets.json and other NuGet files. I'm expecting one of those files to be malformed or incorrect, causing downstream KeyNotFoundException. |
The bad news is I just checked and there are no published artifacts from init.cmd. The good news is I think if we run |
Another bug is that the NullReference exception doesn't print the entire stack trace to the Console, so we don't know where exactly it happened. |
Our Init.ps1 also has this:
We can probably decrease the timeout to 1 second to simulate whatever network fluke we've been seeing. |
I got this just now while running an "update all" in VS 17.8.0 preview 2. (I assume it's the same -- slightly different stack) I don't know how to make a repro, but posting here to say it's still an issue.
|
if (libraryIncludeFlags != LibraryIncludeFlags.All)
{
yield return new LibraryDependency
{
LibraryRange = new LibraryRange(centralPackageVersion.Name, centralPackageVersion.VersionRange, LibraryDependencyTarget.Package),
ReferenceType = LibraryDependencyReferenceType.Transitive,
VersionCentrallyManaged = true,
IncludeType = dictionary[centralPackageVersion.Name], /// <----
SuppressParent = libraryIncludeFlags
}; dictionary contains <title>Document</title>
@heng-liu is this sufficient info? I'm using central package management and may well have configured something wrong, but it presuambly should tell me what. I have a dump file if you want. |
@danmoseley based on your stack trace, I think you're hitting this issue instead: #12464 It should be fixed in the latest 17.8? |
@jeffkl you're probably right. It's not fixed in today's latest 8.0.100 .NET SDK. Is that expected? |
@danmoseley I think I see the fix in 8.x based on what I see in ILSpy: // C:\Program Files\dotnet\sdk\8.0.100-rc.2.23502.2\NuGet.DependencyResolver.Core.dll
// NuGet.DependencyResolver.Core, Version=6.8.0.117, Culture=neutral, PublicKeyToken=31bf3856ad364e35
private static void DetectAndMarkAmbiguousCentralTransitiveDependencies<TItem>(Tracker<TItem> tracker, List<GraphNode<TItem>> centralTransitiveNodes)
{
int count = centralTransitiveNodes.Count;
bool flag;
do
{
flag = false;
for (int i = 0; i < count; i++)
{
if (centralTransitiveNodes[i].Disposition == Disposition.Acceptable && !centralTransitiveNodes[i].ParentNodes.Any((GraphNode<TItem> p) => p.Disposition != Disposition.Rejected && !tracker.IsDisputed(p.Item) && !tracker.IsAmbiguous(p.Item)) && !tracker.IsAmbiguous(centralTransitiveNodes[i].Item))
{
flag = true;
centralTransitiveNodes[i].ForEach(delegate(GraphNode<TItem> x)
{
tracker.MarkAmbiguous(x.Item);
}, (GraphNode<TItem> pn) => tracker.IsAmbiguous(pn.Item));
}
}
}
while (flag);
} That sort of looks like our current code and not the previous implementation. You said you're not sure how to repro it before, is that still the case? |
Is this the same as #12464? |
NuGet Product Used
dotnet.exe
Product Version
5.0.301
Worked before?
No response
Impact
Other
Repro Steps & Context
I ran dotnet restore on my solution on CI after first installing .NET 5.0.301.
I saw a NullReferenceException and a KeyNotFoundException.
Verbose Logs
The text was updated successfully, but these errors were encountered: