Skip to content
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

Merged
merged 8 commits into from
Sep 29, 2022

Conversation

rokonec
Copy link
Contributor

@rokonec rokonec commented Sep 27, 2022

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

Copy link
Member

@rainersigwald rainersigwald left a 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?

src/MSBuild/XMake.cs Outdated Show resolved Hide resolved
src/MSBuild/XMake.cs Outdated Show resolved Hide resolved
src/MSBuild/XMake.cs Outdated Show resolved Hide resolved
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
// 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.
Copy link
Member

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.

Copy link
Contributor Author

@rokonec rokonec Sep 28, 2022

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.

Copy link
Member

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.
Copy link
Member

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.

@rokonec
Copy link
Contributor Author

rokonec commented Sep 29, 2022

I am merging it so it can get into SDK soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Msbuild gets stuck in net7.0 , preventing further builds until reboot
4 participants