artifacts-credprovider: 'dotnet restore' unhandled exception with NuGetCredentialProvider

Hey team,

I’m not sure if this is an issue with the dotnet CLI or with the credential provider. I’ll try this repository first. I’ve also reviewed the other open issues and it this doesn’t appear to be related.

We are using Azure Artifacts and restoring packages in a docker container:

WORKDIR /nuget_cache_warmer
COPY **/*.csproj ./
RUN for f in ./*.csproj; do dotnet restore $f --source $NUGET_SOURCE --source https://api.nuget.org/v3/index.jsonl; done

This is our base image: FROM microsoft/dotnet:2.1-sdk

Intermittently, I start to see:

Unhandled Exception:  [0m [91mSystem.Threading.Tasks.TaskCanceledException: A task was canceled.
NuGet.Protocol.Plugins.MessageDispatcher.DispatchWithNewContextAsync[TOutgoing,TIncoming](IConnection connection, MessageType type, MessageMethod method, TOutgoing payload, CancellationToken cancellationToken) at NuGet.Protocol.Plugins.SymmetricHandshake.HandshakeAsync(CancellationToken cancellationToken) at NuGet.Protocol.Plugins.Connection.ConnectAsync(CancellationToken cancellationToken)
at NuGet.Protocol.Plugins.PluginFactory.CreateFromCurrentProcessAsync(IRequestHandlers requestHandlers, ConnectionOptions options, CancellationToken sessionCancellationToken)
at NuGetCredentialProvider.Program.Main(String[] args)
at NuGetCredentialProvider.Program.<Main>(String[] args)

This happens more than once during the restore processing, but not for every .csproj file.

What is interesting compared to other issues is the restore process will complete, and I can run the next docker step to build my project successfully.

If it matters, the docker build is running on a Linux TeamCity agent. If I run dotnet restore --disable-parallel, the exception does not occur, however the restore takes twice as long (as expected).

Since I can still restore successfully this isn’t a huge problem, though I thought I’d report it.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 15 (15 by maintainers)

Most upvoted comments

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.

Sure, its my github alias at microsoft dot com