-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
dotnet watch causing server to always fail #8006
dotnet watch causing server to always fail #8006
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any way to add a test for this?
// Server node shall terminate after it received CancelKey press. | ||
if (s_isServerNode) | ||
{ | ||
Environment.Exit(0); // the process can now be terminated as everything has already been gracefully cancelled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused—why does the server have to shut down when it's cancelled? I would've expected that just cancelling submissions then waiting for the next build request would've been sufficient.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be consistent with other nodes behavior. When you cancel builds all build nodes are shutdown afterward.
I am not sure why, but the code shows clear intent to do so. I guess, we do not want to deal with processes which might ended up be in inconsistent states caused by build cancellation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. It seems reasonable to want to avoid unknown states at build start. I don't know what would go wrong in this case, but leaving yourself open to unforeseen bugs is bad if it's avoidable, so it seems reasonable to align with that.
// Server node shall terminate after it received CancelKey press. | ||
if (s_isServerNode) | ||
{ | ||
Environment.Exit(0); // the process can now be terminated as everything has already been gracefully cancelled. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok. It seems reasonable to want to avoid unknown states at build start. I don't know what would go wrong in this case, but leaving yourself open to unforeseen bugs is bad if it's avoidable, so it seems reasonable to align with that.
I am merging it so it can get into SDK soon |
Fixes #8010
Context
Theory: dotnet watch stopping was sending Ctrl+C (SIGINT) to its child processes, which is unexpected as CTRL+C is propagated from client by build server packet command through its named pipe.
Server set its cancellation token and all subsequent build has been therefore considered as to be cancelled.
Changes Made
When server recieves Ctrl+C (SIGINT) it now gracefully shut down its build submissions and then terminate.
Testing
Can't repro after code changes.
Notes