A summary about the attempts we tried in
https://github.com/microsoft/playwright/pull/26931 for
https://github.com/microsoft/playwright/issues/26859 and
https://github.com/microsoft/playwright/issues/24591.
1. attempt: collect all the stdio from the worker host.
- this made it hard to capture the live console logs for the live trace
2. attempt: collect all the stdio from the worker host, but keep
proxying `process.{stdout,stderr}.write`.
- this solved the live console logs problem, since we could still listen
on them
- we found out about a race that the stdout/stderr streams can still
buffer data while the test already had finished
- we created a best effort flush implementation but didn't like the
complexity it introduced to the project
3. attempt: keep things like they are but also listen to stdio from the
worker host
- this solves the race of console.log in the test (things stay like they
are)
- this keeps live trace working (things stay like they are)
- a known pitfall is that it could result in logs which don't end up in
the reporter onStdOut/onStdErr, but it is already a significant
improvement over how it was before.
- before: they were not getting displayed
- after: they are getting displayed and there is a low likelihood that
they don't end up in the reporter API if the write happens slightly
before a test finished.
Closes#26931Fixes#26859Fixes#24591
- remove error details from the reports
- collapse flaky tests by default
- limit comment to 65365 character
GitHub API has comment length limit 65536 chars:
```
Unhandled error: HttpError: Validation Failed: {"resource":"IssueComment","code":"unprocessable","field":"data","message":"Body is too long (maximum is 65536 characters)"}
```
The call was added back in 2019 to stop network loading. See commit:
56a48559c2
However, there's no evidence that this call is needed any more:
- all the tests pass without it
- `window.stop()` behavior is poorly defined, so relying on it is
unfortunate.
The `window.stop()` call, however, causes trouble while rolling firefox:
under certain condititions, the call prevents document from firing the
`load` event in the `document.open().write(..).close()` sequence that
comes immediately after the call. While this does look like a bug in
Firefox itself, we failed to reproduce it in isolation.
For the reference, the following tests fail with the Firefox 116 (using
`PWTEST_TRACE=1` triggers the race condition somewhere):
```bash
PWTEST_TRACE=1 npm run ftest cli-codegen
```
