-
Notifications
You must be signed in to change notification settings - Fork 706
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
Change exit timeout to start ticking on a shutdown request, not at startup #143
Comments
I don't think I wrote the offending line originally, so I don't know the original intent, but I think the right behavior is to make it a shutdown timeout, not an overall operation timeout |
Can you please elaborate? |
A timeout for the plugin to finish shutting down once a shutdown request has been received |
@jmyersmsft Closing as it seems like you don't add milestone labels, so it's not necessary to be done from your side. |
The plugin lifetime in NuGet is managed by idleness.
That means after a certain period of time, NuGet will shutdown the plugin process.
When running in plugin mode, the plugin currently has a 2 min timeout, regardless of what happens.
See:
artifacts-credprovider/CredentialProvider.Microsoft/Program.cs
Lines 225 to 230 in bea5573
Large solution restores can sometimes last more than 2 minutes. In those cases, the plugin dies and reports an error to NuGet.
NuGet logs that error to stderr.
If NuGet needs the plugin for any other purpose throughout the lifetime of the operation, it will start another plugin process and do that successfully.
So the overall operation succeeds, as far as NuGet is concerned.
It's a common for tooling/CIs to rely on the stderr as a signal of any issues, see:
https://dev.azure.com/dnceng/internal/_build/results?buildId=405076
Windows Build UAP_x86_Release
That fails their whole build operation.
I think the action from the plugin side should be the following:
The plugin infrastructure provides a way to monitor the process exit.
//cc @jmyersmsft @dtivel @rrelyea
Note that all of the tests I have done contain 4 NuGet side fixes. If you were to take stock nuget(5.3 and older) + plugin you might not experience this.
Related fixes:
Related issue: NuGet/Home#8528
The text was updated successfully, but these errors were encountered: