@zivkan do you have any idea what's up with the tests on the single failing leg?

I was going to write that there are a (large?) number of Nuget's tests that are just a little bit flakey, but when I looked at the test's history, this specific test doesn't have any other failures in the test history. Plus, the stack trace shows the error is coming from shows it's coming from Interop.Sys.GetCwd, which almost certainly means the Environment.CurrentDirectory API (or something equivalent), which doesn't seem like it should be possible to fail. So, I'm tempted to say this is some kind of flakiness in the .NET runtime. But I also can't prove that the test directory wasn't somehow deleted before the current directory API was called.

Anyway, I clicked the button to retry failed tests, so it'll probably pass on retry.

Well, it failed again on the same test with the same error, which increases the chance that it might somehow be related to something in this PR, but I'm struggling to imagine what it could possibly be ☹️

I was going to write that there are a (large?) number of Nuget's tests that are just a little bit flakey, but when I looked at the test's history, this specific test doesn't have any other failures in the test history. Plus, the stack trace shows the error is coming from shows it's coming from Interop.Sys.GetCwd, which almost certainly means the Environment.CurrentDirectory API (or something equivalent), which doesn't seem like it should be possible to fail. So, I'm tempted to say this is some kind of flakiness in the .NET runtime. But I also can't prove that the test directory wasn't somehow deleted before the current directory API was called.

Anyway, I clicked the button to retry failed tests, so it'll probably pass on retry.

Hypothesis: More async-stuff is happening with this PR, so if base-platform level syscalls require thread synchronization it's possible that might need to be adhered to? Maybe sprinkling .ConfigureAwait(false) everywhere there's new async code in this PR?

Hypothesis: More async-stuff is happening with this PR, so if base-platform level syscalls require thread synchronization it's possible that might need to be adhered to? Maybe sprinkling .ConfigureAwait(false) everywhere there's new async code in this PR?

dotnet nuget locals is a console app command, just like all other dotnet cli commands, which doesn't use a SynchronizationContext. Therefore, I'd expect all async work to be happening on ThreadPool.Default already. .ConfigureAwait(false) should therefore be a no-op, given my understanding of how async works on .NET.

Personally, I think it's more likely that some method that was made async is not being awaited, allowing some method to exit before the async work happens. This makes a good case for always renaming methods that are made async to append the Async suffix, because if there are any places where the call is not modified, you'll get a compiler error, making it very clear you need to update the method name being called, in addition to adding the await keyword.

However, I don't see any files modified that dotnet nuget locals might be using. So, maybe my advice should be ignored because I have no idea what's going on 🤣

The fact that the test also fails only on Mac, not on Linux or Windows makes it even more mysterious. I keep writing questions like "have you tried running the test locally", but unless you have a Mac, it doesn't really matter. It's a fresh day today, but I didn't get any new ideas on how to diagnose or fix the failing test.

@baronfel we had to merge a commit to fix CI, when you have time please rebase your branch and push, or let me know if you want me to do it on your behalf.

Thanks for the poke @jeffkl - I've rebased it now.

@jeffkl it looks like the windows tests failed on a new test I added. Progress! The tests triggered hang dump generation, but I don't think the dumps were collected:

  Results File: D:\a\_work\_temp\cloudtest_a160b5fcc000000_2025-01-23_23_32_51.trx
  
  Attachments:
    D:\a\_work\_temp\fb9a4a04-24c0-4ece-9f18-d3b953f1b4da\testhost_4224_20250123T233936_hangdump.dmp
    D:\a\_work\_temp\fb9a4a04-24c0-4ece-9f18-d3b953f1b4da\Sequence_c3fe1a81c93a4f98adce715806e0e90c.xml

Is it possible for those to be collected?

Is it possible for those to be collected?

@baronfel, they are attached to the test run: https://dev.azure.com/dnceng-public/public/_build/results?buildId=927284&view=ms.vss-test-web.build-test-results-tab&runId=24546252&paneView=attachments&resultId=0

@jeffkl perfect, thank you for the pointer!

As expected, it's the new test (specifically the slnx test case) that's failing here:

<Test Name="NuGet.XPlat.FuncTest.ListPackageTests.CanListPackagesForProjectsInSolutions" DisplayName="NuGet.XPlat.FuncTest.ListPackageTests.CanListPackagesForProjectsInSolutions(useSlnx: True)" Source="D:\a\_work\1\s\test\NuGet.Core.FuncTests\NuGet.XPlat.FuncTest\bin\Debug\net8.0\NuGet.XPlat.FuncTest.dll" Completed="False" />

All other cases are completing.

@jeffkl !!! It's green, quick merge it!

@jeffkl !!! It's green, quick merge it!

How did you end up fixing the test failure?

I don't see anything right now.
Did it just go away?

Yeah, a re-run cleared it up.

This is too late for 9.0.200 GA at this point, but is this the kind of thing that would be amenable to a servicing backport? The rest of the SDK will have great support for slnx in 9.0.200 and I'm concerned about users having a pit of failure with package management as they onboard to slnx.

It's not quite servicing since it has not GA yet, so "technically" just a QB insertion.

I'd suggest reaching out to @aortiz-msft about that.