Looking at the original issue, the user report shows spin watch rather than spin build. Has this been observed with spin build too? spin watch does a bunch of extra stuff, and does set up a Ctrl+C handler.

Yeah I can repro this with spin watch if the first build fails. Investigating.

The problem happens because Ctrl+C handler sends a stop message (which happens correctly), but the loop that receives that message and responds to it by exiting is paused until after the first successful build (behaviour introduced in #2096). The build loop correctly circles back to the top and waits for changes (if you make a source code change, you'll see a rebuild), but until the first successful build, the stop message can't be processed.

(After a successful build, the second loop is unpaused. It will pause again temporarily during builds, but always resumes whether the build succeeded or failed. So stop message processing may get delayed but will happen.)

I think the fix is to pull the stop message receiver out into its own task, so that is can be included in the top level select and bring down the whole house without needing involvement from the change monitoring loops. I don't think that will terminate child processes correctly. Changing plans.

The simplest fix seemed to be to have the Ctrl+C handler unpause the loop that receives the message. PR sent.