fix: process exit before stdout/stderr are properly flushed

[Moumouls]

• Closes No issues

Additional details

ON CI envs ( like github actions ), processs exit can terminate the process before stdout/stderr are properly flushed.
It lead to a cropped result summary table

---

Note

Prevents truncated terminal output in CI by guaranteeing buffered streams flush before exit.

• Adds waitForStreamDrain() and awaits it for process.stdout and process.stderr in packages/server/lib/cypress.ts exit()
• Includes a 5s safety timeout and debug logs while waiting
• Updates cli/CHANGELOG.md with 15.8.3 bugfix entry describing the CI output cut-off fix

^{Written by Cursor Bugbot for commit 3a128d6. This will update automatically on new commits. Configure here.}

Steps to test

Create a lot of specs files, run Cypress on Ci env like Github Action, the result summary table is cropped.

How has the user experience changed?

No change

PR Tasks

Not sure how to add tests for this one.

• Have tests been added/updated?
• Has a PR for user-facing changes been opened in cypress-documentation?
• Have API changes been updated in the type definitions?

[CLAassistant]

All committers have signed the CLA.

[cypress-app-bot]

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.

[Moumouls]

not sure why semantic PR is not happy, i added the suggested line to line 4

[jennifer-shehane]

@Moumouls Do you have an example output / screenshot of what this looks like? I can't say that I've seen this exactly before.

[cursor]

Stream drain event may not fire causing unnecessary delay

Medium Severity

The waitForStreamDrain function waits for the 'drain' event when writableLength > 0. However, Node.js only emits the 'drain' event after a write() call returns false (indicating the buffer was full). If there's buffered data but all writes succeeded (returned true), the 'drain' event will never fire, causing the code to always wait for the 5-second safety timeout. This could add significant delays to CI builds. A more reliable approach would be to poll writableLength until it reaches 0, or use setImmediate to allow the event loop to flush pending writes.

 

[jennifer-shehane]

@Moumouls Could you address whether this comment is relevant?

[Moumouls]

I’m not 100% sure about the correct approach here. The issue is very “low-level,” and I’m not an expert in that area. I was helped by Opus on this task, and the code seems logically sound. Does anyone on the Cypress team have expertise in this kind of stuff?

The 5-second timeout at the end of a full spec run doesn’t seem like an issue to me.

However, I’m not sure what the best approach is to ensure things happen ASAP and to verify that all logs are properly flushed.

If I were coding it myself, I’d probably go with a 1–3 second timeout. I believe that should be sufficient, since this feels more like a millisecond or nanosecond-level issue.

[Moumouls]

sure @jennifer-shehane

Here an example :

We tried a patch like this to capture the exit code, because we thought it was a GitHub Actions issue (and it still might be). That’s why, in my screenshot, you can see the coverage summary, but it’s cropped.

yarn cypress:run --browser chrome --config-file cypress.config.ts; EXIT_CODE=$?; sleep 3; nyc report --reporter=text-summary; exit $EXIT_CODE

I asked Opus 4.5, and it seems that nothing guarantees a process will wait for all standard streams to be fully flushed before exiting. In GitHub Actions, this means the exit code can be received and log streaming can be shut down before the full log has been transmitted.

The issue seems also random sometimes we have the full report, so it sounds there is a race between the exit code and the STD.

Example of a good working one ( with same scripts)

So my conclusion is: cypress seems to exit a little bit too fast, and it should wait a little bit to ensure in CI envs all the logs are correctly flushed

[Moumouls]

@jennifer-shehane don't hesitate to tell me what i can do to help this PR to move forward !

The issue is quite annoying on our CI ahahha

[coratgerl]

I have the same issue @jennifer-shehane, do you have any ETA for this one 🙏 ?

[Moumouls]

Hi @jennifer-shehane, we’re still experiencing this issue. What can we do to help get this PR into the next release?