Electron Releases

Description of Change

The three app.setPath() > sessionData specs failed together on Windows CI. "writes to userData by default" hit the 30 s test timeout with none of the fixture app's output. Then the other two failed in beforeEach with EPERM removing the fixture's default userData directory.

They all ran the same fixture, so they shared its default userData directory (appData/<name>), and each removed it in beforeEach without retrying. When the first run timed out, the app's child processes outlived it and kept files there open.

• Each spec now runs its own copy of the fixture under a name of its own, so it has its own default userData directory. The redirect specs write into the copy's directory, and no spec touches another's files.
• Removing them is best effort: it keeps trying for 5 seconds, then logs the error and moves on. A beforeAll sweeps up leftovers from earlier runs, skipping anything from the last hour in case another run is still using it.

The timeout lost the app's output because spawnAndWait() waits for 'close'. That also waits for the child's stdout and stderr to close, and Windows testing builds hand both to their sandboxed child processes, so one that outlives the killed app keeps them open. Once spawnAndWait() has timed out, it now stops reading a second after the child exits. It then throws its usual timeout error with the output it has, and says when stdout or stderr stayed open. Runs that don't time out behave exactly as before.

The fixture also waited for the timeout when its page failed, when the page failed to load, when its renderer crashed, or on an uncaught exception. It now exits with the first such error, ignoring anything that follows from it or from quitting. It also logs each step as it starts, so a timeout shows how far it got.

Validation on Linux under Xvfb, with retries off. Linux can delete open files, so the Windows EPERM itself can't happen here. Throwaway controls stood in for it:

• A detached process kept writing into the first spec's directory after its run was killed. On main, the other two specs failed at once, which is the same cascade. With this change they pass.
• A hung fixture with a child process holding its inherited stdout and stderr. On main, that ended in the 30 s test timeout with no output, the recorded symptom. Now spawnAndWait() fails at 21 s with its own error and every step line.
• A rejected service worker registration, a failed load, a renderer crash during and after the load, and an uncaught exception. Each one fails in well under a second, printing only its real cause.
• The sessionData specs passed 10/10 runs, and other spawnAndWait() users (esm.spec.ts, and parts of node.spec.ts and api-protocol.spec.ts) still pass.

🤖 Generated with Claude Code

Checklist

• I have built and tested this change
• I have filled out the PR description
• I have reviewed and verified the changes
• tests are changed or added

Release Notes

Notes: none