'dotnet restore' unhandled exception with NuGetCredentialProvider about artifacts-credprovider HOT 15 CLOSED

Sure, its my github alias at microsoft dot com

from artifacts-credprovider.

To your earlier point about not using upstreams - yes, cached packages do get charged the same manually pushed packages do.

When it comes to retention policies though, currently the packages that you don't want retention policies to delete, you can promote to a view. Packages that are in views are "safe" from retention policies because there's no way to "unpromote" other than manually deleting the package. However, we're planning to revisit the retention/immutability space in the near future to determine if the current experience is the right approach so, if you're interested in chatting about it more, the Artifacts program manager @elbatk is available.

from artifacts-credprovider.

This could be a docker issue or related to this open issue with dotnet NuGet/Home#7842.
FYI @shubham90 who worked on the docker implementation - I forgot if the TaskCanceledException was resolved with some of the docker images?

from artifacts-credprovider.

Hello @satbai, yes that seems somewhat related. What's odd though is I've tested it on two different projects and although I see the same exception, the restore process still completes successfully. Unlike the issue you've referenced, it appears that the restore process exits with error code 1.

I'd appreciate if @shubham90 has anything to share. I'm rolling this out to our org and I'd like to make sure it's safe to proceed.

from artifacts-credprovider.

Could you run the same command with detailed verbosity and share the logs please? I'm interested in seeing the detailed cred provider logs. The verbose logs should also show the cred provider version. Also, if you're not using the latest version cred provider, I'd recommend updating it.

from artifacts-credprovider.

Hey @satbai, can I get your e-mail address that I can send the logs to? I don't want to leak sensitive info in the logs, if there are any (it's pretty long).

from artifacts-credprovider.

Thanks for the logs!

After looking at the logs, I think what's happening is this:
The nuget.config file has two endpoints, an Azure Artifacts feed and api.nuget.org endpoint. Nuget thinks it needs credentials to get a package from the Artifacts feed so it launches the cred provider but all packages get fetched from nuget.org before the cred provider even starts logging. Since the task finished, the cred provider gets canceled. This is a valid cancellation scenario, so there seems to be a bug in the cancellation handling.

I think the cancellation doesn't interrupt the build because the task that threw the exception is already finished so there's no task to stop processing. The build is already processing the next step.

To get rid of the exceptions, as a workaround, what I think will help is to remove one of the package source endpoints from nuget.config, because it looks like the same packages can be found in both endpoints.

There are some fixes in related areas in the next nuget/dotnet release that's coming soon, I think later this month, so I'd like to see if the new version will get rid of these exceptions. If this isn't fixed with the new version, we'll have to dive deeper to see why a valid cancellation scenario throws unhandled TaskCanceledExceptions.

from artifacts-credprovider.

Thanks a lot @satbai! We don't cache packages on Azure Artifacts from the public feed so unfortunately we do pass both feeds using the --source parameter.

Do you think that this could end up failing a build periodically, if the task it's trying to handle doesn't shut down in time?

I'm hoping I can get your advice: I'm migrating our systems to use Azure Artifacts and I am not sure if I should wait for a fix for this problem or go ahead with the change because the error appears to be harmless. What would you suggest based on your findings?

from artifacts-credprovider.

I might be mistaken, but if my assumptions are correct, theoretically it's possible that sometimes the build might actually fail. My confidence in this area is limited though, so adding @nkolev92 and @dtivel to make sure my theory makes sense in the nuget/dotnet side.

1. Do you agree that unhandled TaskCanceledException shouldn't be thrown if the restore task finishes using nuget.org package source endpoint while trying to launch the plugin cred provider to authenticate to an Artifacts feed, because the packages can be found in both sources? Instead, the cancellation in this case is valid and expected?
2. In my previous comment, I mentioned "I think the cancellation doesn't interrupt the build because the task that threw the exception is already finished so there's no task to stop processing. The build is already processing the next step." Does this theory make sense? Is that how nuget/dotnet handles exceptions?

"We don't cache packages on Azure Artifacts from the public feed so unfortunately we do pass both feeds using the --source parameter."

@AMoghrabi, do you mean that you prefer not to use nuget.org as an upstream source in the Artifacts feed? Setting that upstream source would likely solve this.

from artifacts-credprovider.

@satbai Sorry for the delay!

That's correct -- we prefer not to set nuget.org as an upstream for two reasons:

1. If, for some reason an upstream package is deleted from Azure Artifacts, the version number cannot be reused. This may cause problems with retention policies. Actually I'm not really sure how the policies work in regards to cached packages, but we couldn't find any information on this online and we want to avoid it altogether.

2. We prefer not to pay for cached packages 😬 On our private nuget server that we're migrating from, we have about 10GB of cached packages from nuget.org.

I'll review the email that you sent me yesterday to see if I can find a workaround.

from artifacts-credprovider.

@satbai, I agree that an unhandled TaskCanceledException should not be thrown in the scenario you describe. A TaskCanceledException should be thrown, but it should be handled.

I recommend that you catch TaskCanceledException here and silently exit.

from artifacts-credprovider.

I can look into making that change if you're busy @satbai 😄

from artifacts-credprovider.

@AMoghrabi thanks for preparing the PR and sorry for the delay - I was out of office for some time. I'll have a look at the PR today!

from artifacts-credprovider.

Linking to NuGet/Home#8528, as there may be another fix needed in NuGet to resolve this. I'm guessing we'll also still want to catch TaskCanceledException during credprovider handshake and exit cleanly (@AMoghrabi's PR), though I'm going to wait until the issue(s) are truly fully understood before merging that.

from artifacts-credprovider.

Thanks for the help everyone, closing this as Jonathan released a new version with my fix.

from artifacts-credprovider.