Studio: Fix stop server error

[kozer]

Fixes: https://github.com/Automattic/dotcom-forge/issues/7245

Proposed Changes

This PR fixes a bug when a user start/stops the server multiple times, child process exits with error 15

Testing Instructions

1. Start Studio, and start/stop a site in the studio multiple times.
2. Ensure that an error is logged in from time to time, but there is no unhandled errors.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[kozer]

I really don't know what caused this to exit with status code 15. However, just catching the error, solves the crash.
If anyone has any insights, I'd love to discuss this more.

[dcalhoun]

I attached the related STUDIO-BE Sentry report to the issue.

I really don't know what caused this to exit with status code 15. However, just catching the error, solves the crash. If anyone has any insights, I'd love to discuss this more.

Given @fluiddot built the utility process in #19, he may have insight to share.

In the Sentry report, I note two sites are stopped with 'Utility' process exited with 'killed' and exitCode: 15, but only the latter appears to report an exception.

[fluiddot]

Given @fluiddot built the utility process in #19, he may have insight to share.

In the Sentry report, I note two sites are stopped with 'Utility' process exited with 'killed' and exitCode: 15, but only the latter appears to report an exception.

I can't reproduce this issue on macOS, so I wonder if it's specific to Linux. The exit code 15 is not listed in node's exit codes. However, the value might correspond to exiting the process due to a SIGTERM signal, whose code is 15. When a node's process is terminated by a signal, in theory, the exit code is 128 + Signal code. In this. case, it should be 143 (128 + 15), but maybe it directly returned the signal code instead 🤔.

[fluiddot]

Since killProcess is a private function that will only be called by stop, I wonder if the error handling should be located there. With this approach, the promise will be resolved for any exit code, but for non-zero codes we'll report an error in Sentry. WDYT?

[dcalhoun]

[...] The exit code 15 is not listed in node's exit codes. However, the value might correspond to exiting the process due to a SIGTERM signal, whose code is 15. When a node's process is terminated by a signal, in theory, the exit code is 128 + Signal code. In this. case, it should be 143 (128 + 15), but maybe it directly returned the signal code instead 🤔.

Interesting. I was not aware that. Honestly, I had a hard time following which source/documentation applied to Electron's utilityProcess. I did locate a 15 error code in Chromium's source — I wondered if that could possibly represent the error code we are seeing.

Since killProcess is a private function that will only be called by stop, I wonder if the error handling should be located there. With this approach, the promise will be resolved for any exit code, but for non-zero codes we'll report an error in Sentry. WDYT?

Makes sense to me. 👍🏻

[fluiddot]

Interesting. I was not aware that. Honestly, I had a hard time following which source/documentation applied to Electron's utilityProcess. [...]

Yeah, it's not easy to pinpoint the source of the error codes.

[...] I did locate a 15 error code in Chromium's source — I wondered if that could possibly represent the error code we are seeing.

Ah, interesting. It seems that the utilityProcess uses Chromium behind the scenes, specifically, the documentation references a library named Mojo (reference). I thought it might be using node processes but based on this, it's likely the exit code is related to Chromium.

[kozer]

@fluiddot , @dcalhoun , very interesting finding!! Thanks for taking a deeper look!
I updated the code and moved error handling and reporting inside #killProcess function.

[fluiddot]

LGTM 🎊 !