fix: deliver pending utilityProcess messages before emitting exit by claude[bot] · Pull Request #54924 · electron/electron

claude · 2026-10-14T17:14:41Z

Requested by John Kleinschmidt · Slack thread

Description of Change

UtilityProcessWrapper::HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had already posted but the main process had not dispatched yet were dropped. The connector dispatches one message per task, and the child's exit notification can already be queued ahead of those tasks, so a child that does process.parentPort.postMessage(...) a few times and then process.exit(0) loses everything after the first message. @ckerr found this while reviewing #54901, where a spec fixture needed an ack handshake to work around it. Now that #54901 has landed, this PR also removes that handshake from spec/fixtures/api/utility-process/api-net-spec.js and waitForUtilityResult.

This change dispatches whatever is already queued on the port before closing it, so those messages are emitted before 'exit'. It only reads messages that are already there and never blocks. Browser shutdown (Shutdown()) still closes the port without dispatching, because the child is still running at that point.

The new spec has the child post 20 messages and exit while the main thread is briefly blocked. On 46.0.0-nightly.20261014 it failed in all 6 runs that completed (only message 0 arrived before 'exit'; 2 more runs died to an unrelated vitest worker start failure in my container). I did not compile the C++ change locally, so CI is the first build of it.

Checklist

I have filled out the PR description
tests are changed or added
PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, past tense, and no longer than 80 characters.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS

Release Notes

Notes: Fixed utilityProcess dropping messages posted with process.parentPort.postMessage() right before the process exits.

Generated by Claude Code

HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had posted but the browser had not dispatched yet were dropped. The connector dispatches one message per task, and the exit notification can already be queued ahead of those tasks, so a child that posts several messages and then calls process.exit() lost all but the first. Dispatch whatever is already queued on the port before closing it. Browser shutdown still closes the port without dispatching, since the child is still running then. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS

dsanders11

@claude, since #54901 landed can you fold the change mentioned in https://github.com/electron/electron/pull/54901/changes#r4274263333 into this PR?

…s-drain-on-exit

Move the Atomics.wait() call in the utilityProcess message-before-exit test into a documented sleepSync() spec helper. With pending parentPort messages now dispatched before 'exit', the api-net-spec.js fixture can post its result and exit right away again, so remove the ack handshake that #54901 added as a workaround, along with the error logging that covered the wait for the ack. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS

claude · 2026-10-14T21:52:40Z

Addressed in 5b92d8c (after merging main to pick up #54901):

Folded in the change from test: fix flaky specs that relied on the individual-test rerun #54901 (comment): the ack handshake is gone. api-net-spec.js posts its result and exits right away again, waitForUtilityResult no longer sends an ack, and the uncaughtException/unhandledRejection logging that covered the wait for the ack and the helper's ack unit test are removed too. The fixture and helper are back to what they were before test: fix flaky specs that relied on the individual-test rerun #54901.
The Atomics.wait() one-off is now a documented sleepSync() helper in spec/lib/spec-helpers.ts.

On 46.0.0-nightly.20261014 (which doesn't include the C++ fix), the utility-process api-net tests pass without the handshake, and the new test still fails as expected with sleepSync.

Generated by Claude Code

release-clerk · 2026-10-14T22:59:42Z

Release Notes Persisted

Fixed utilityProcess dropping messages posted with process.parentPort.postMessage() right before the process exits.

trop · 2026-10-14T22:59:50Z

I was unable to backport this PR to "42-x-y" cleanly;
you will need to perform this backport manually.

trop · 2026-10-14T22:59:53Z

I was unable to backport this PR to "43-x-y" cleanly;
you will need to perform this backport manually.

trop · 2026-10-14T22:59:56Z

I was unable to backport this PR to "45-x-y" cleanly;
you will need to perform this backport manually.

trop · 2026-10-14T22:59:59Z

I was unable to backport this PR to "44-x-y" cleanly;
you will need to perform this backport manually.

trop · 2026-10-15T00:38:19Z

claude[bot] has manually backported this PR to "43-x-y", please check out #54962

…4960) fix: deliver pending utilityProcess messages before emitting exit (#54924) * fix: deliver pending utilityProcess messages before emitting exit HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had posted but the browser had not dispatched yet were dropped. The connector dispatches one message per task, and the exit notification can already be queued ahead of those tasks, so a child that posts several messages and then calls process.exit() lost all but the first. Dispatch whatever is already queued on the port before closing it. Browser shutdown still closes the port without dispatching, since the child is still running then. Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS * test: extract sleepSync helper and drop utility-process ack handshake Move the Atomics.wait() call in the utilityProcess message-before-exit test into a documented sleepSync() spec helper. With pending parentPort messages now dispatched before 'exit', the api-net-spec.js fixture can post its result and exit right away again, so remove the ack handshake that #54901 added as a workaround, along with the error logging that covered the wait for the ack. Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS (cherry picked from commit 4a802b0) Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>

HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had posted but the browser had not dispatched yet were dropped. The connector dispatches one message per task, and the exit notification can already be queued ahead of those tasks, so a child that posts several messages and then calls process.exit() lost all but the first. Dispatch whatever is already queued on the port before closing it. Browser shutdown still closes the port without dispatching, since the child is still running then. Also extract a sleepSync helper for the new spec, and drop the utility-process ack handshake that #54901 added as a workaround, since pending parentPort messages are now dispatched before 'exit'. Manual backport of #54924. Conflicts resolved: the header only adds the DispatchPendingMessages() declaration (43-x-y has no CloseStdioReadFds()), and the spec imports sleepSync into 43-x-y's existing spec-helpers import. (cherry picked from commit 4a802b0) (cherry picked from commit 53d6d27) Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS

trop · 2026-10-15T06:21:45Z

claude[bot] has manually backported this PR to "42-x-y", please check out #55000

…4962) HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had posted but the browser had not dispatched yet were dropped. The connector dispatches one message per task, and the exit notification can already be queued ahead of those tasks, so a child that posts several messages and then calls process.exit() lost all but the first. Dispatch whatever is already queued on the port before closing it. Browser shutdown still closes the port without dispatching, since the child is still running then. Also extract a sleepSync helper for the new spec, and drop the utility-process ack handshake that #54901 added as a workaround, since pending parentPort messages are now dispatched before 'exit'. Manual backport of #54924. Conflicts resolved: the header only adds the DispatchPendingMessages() declaration (43-x-y has no CloseStdioReadFds()), and the spec imports sleepSync into 43-x-y's existing spec-helpers import. (cherry picked from commit 4a802b0) (cherry picked from commit 53d6d27) Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS Co-authored-by: Claude <noreply@anthropic.com>

…5000) HandleTermination closed the parentPort connector before emitting 'exit', so messages the child had posted but the browser had not dispatched yet were dropped. The connector dispatches one message per task, and the exit notification can already be queued ahead of those tasks, so a child that posts several messages and then calls process.exit() lost all but the first. Dispatch whatever is already queued on the port before closing it. Browser shutdown still closes the port without dispatching, since the child is still running then. Also extract a sleepSync helper for the new spec, and drop the utility-process ack handshake that #54901 added as a workaround, since pending parentPort messages are now dispatched before 'exit'. Manual backport of #54924. Conflicts resolved: the header only adds the DispatchPendingMessages() declaration (42-x-y has no CloseStdioReadFds()). The spec's sleepSync import merged cleanly into 42-x-y's existing spec-helpers import. (cherry picked from commit 4a802b0) (cherry picked from commit 53d6d27) Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS Co-authored-by: Claude <noreply@anthropic.com>

process.exit() does not wait for pending postMessage() writes, so a utility child that exits right after posting can lose its message. Restore the acknowledgement handshake that #54924 removed from the api-net fixture and helper, and add it to the env-app and js2c-code-cache fixtures, so those children only exit once the parent has acknowledged their message. The #54924 test no longer posts right before exiting. The child posts its parentPort messages, then posts on a transferred MessagePortMain and exits only when the parent replies there. parentPort and the port share the same ordered Mojo channel, so all of the parentPort messages have reached the parent when the port message does. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS

process.exit() does not wait for pending postMessage() writes, so a utility child that exits right after posting can lose its message. Restore the acknowledgement handshake that #54924 removed from the api-net fixture and helper, and add it to the env-app and js2c-code-cache fixtures, so those children only exit once the parent has acknowledged their message. The #54924 test no longer posts right before exiting. The child posts its parentPort messages, then posts on a transferred MessagePortMain and exits only when the parent replies there. parentPort and the port share the same ordered Mojo channel, so all of the parentPort messages have reached the parent when the port message does. Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS Co-authored-by: Claude <noreply@anthropic.com>

process.exit() does not wait for pending postMessage() writes, so a utility child that exits right after posting can lose its message. Restore the acknowledgement handshake that #54924 removed from the api-net fixture and helper, and add it to the env-app and js2c-code-cache fixtures, so those children only exit once the parent has acknowledged their message. The #54924 test no longer posts right before exiting. The child posts its parentPort messages, then posts on a transferred MessagePortMain and exits only when the parent replies there. parentPort and the port share the same ordered Mojo channel, so all of the parentPort messages have reached the parent when the port message does. Claude-Session: https://claude.ai/code/session_01LPMvJBQiyP6b7QjatACmnS Co-authored-by: trop[bot] <37223003+trop[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>

ckerr mentioned this pull request Oct 14, 2026

test: fix flaky specs that relied on the individual-test rerun #54901

Merged

3 tasks done

claude Bot marked this pull request as ready for review October 14, 2026 20:57

jkleinsc approved these changes Oct 14, 2026

View reviewed changes

dsanders11 requested changes Oct 14, 2026

View reviewed changes

Comment thread spec/api-utility-process.spec.ts Outdated

claude added 2 commits October 14, 2026 21:49

Merge remote-tracking branch 'origin/main' into claude/utility-proces…

d1ee83b

…s-drain-on-exit

claude Bot requested a review from dsanders11 October 14, 2026 21:52

dsanders11 approved these changes Oct 14, 2026

View reviewed changes

jkleinsc merged commit 4a802b0 into main Oct 14, 2026
77 of 78 checks passed

jkleinsc deleted the claude/utility-process-drain-on-exit branch October 14, 2026 22:59

github-actions Bot added the 46-x-y label Oct 14, 2026

trop Bot removed the target/42-x-y PR should also be added to the "42-x-y" branch. label Oct 14, 2026

trop Bot added needs-manual-bp/42-x-y and removed target/43-x-y PR should also be added to the "43-x-y" branch. labels Oct 14, 2026

trop Bot added needs-manual-bp/43-x-y needs-manual-bp/45-x-y and removed target/45-x-y PR should also be added to the "45-x-y" branch. target/44-x-y PR should also be added to the "44-x-y" branch. labels Oct 14, 2026

trop Bot mentioned this pull request Oct 15, 2026

fix: deliver pending utilityProcess messages before emitting exit #54960

Merged

trop Bot added in-flight/44-x-y and removed needs-manual-bp/44-x-y labels Oct 15, 2026

claude Bot mentioned this pull request Oct 15, 2026

fix: deliver pending utilityProcess messages before emitting exit #54962

Merged

4 of 6 tasks

trop Bot added in-flight/43-x-y and removed needs-manual-bp/43-x-y labels Oct 15, 2026

trop Bot added merged/44-x-y PR was merged to the "44-x-y" branch. and removed in-flight/44-x-y labels Oct 15, 2026

claude Bot mentioned this pull request Oct 15, 2026

fix: deliver pending utilityProcess messages before emitting exit #55000

Merged

3 of 5 tasks

trop Bot added in-flight/42-x-y and removed needs-manual-bp/42-x-y labels Oct 15, 2026

trop Bot added merged/43-x-y PR was merged to the "43-x-y" branch. and removed in-flight/43-x-y labels Oct 15, 2026

trop Bot added merged/42-x-y PR was merged to the "42-x-y" branch. and removed in-flight/42-x-y labels Oct 15, 2026

claude Bot mentioned this pull request Oct 17, 2026

test: wait for the parent's ack before utility children exit #55082

Merged

2 tasks done

claude Bot mentioned this pull request Oct 20, 2026

build: remove the spec runner's end-of-job individual test rerun #55134

Merged

2 of 3 tasks

electron-release-board Bot added this to 46-x-y Oct 27, 2026

Navigation Menu

Repository navigation

fix: deliver pending utilityProcess messages before emitting exit - #54924

fix: deliver pending utilityProcess messages before emitting exit#54924
jkleinsc merged 3 commits into
mainfrom
claude/utility-process-drain-on-exit

claude Bot commented Oct 14, 2026 •

edited

Loading

Uh oh!

dsanders11 left a comment

Uh oh!

Uh oh!

claude Bot commented Oct 14, 2026

Uh oh!

Uh oh!

release-clerk Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 15, 2026

Uh oh!

trop Bot commented Oct 15, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

claude Bot commented Oct 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description of Change

Checklist

Release Notes

Uh oh!

dsanders11 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

claude Bot commented Oct 14, 2026

Uh oh!

Uh oh!

release-clerk Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 14, 2026

Uh oh!

trop Bot commented Oct 15, 2026

Uh oh!

trop Bot commented Oct 15, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

claude Bot commented Oct 14, 2026 •

edited

Loading