Preserve AggregateError nested errors in reporter output

[charliesheh]

Summary
Preserve AggregateError.errors[] entries when filtering and serializing stack traces for reporter output.
Previously, filterStackTrace() recursively preserved error.cause, but omitted nested errors contained in AggregateError.errors[].

Changes

• Added recursive serialization support for AggregateError.errors[]
• Preserved nested aggregate sub-errors in reporter output
• Added regression coverage in reporter-base.spec.ts

Testing

• npm run build
• npm run ttest -- tests/playwright-test/reporter-base.spec.ts

[charliesheh]

@microsoft-github-policy-service agree

[Zelys-DFKH]

Hey @charliesheh, the filterStackTrace change is exactly right, and the instanceof AggregateError guard is the correct approach. Nice work tracking that down.

A few more pieces need to land before this is fully wired up.

The IPC boundary is the one that'll bite. TestInfoErrorPayload in packages/playwright/src/common/ipc.ts needs an errors? field, and toTestInfoErrorPayload() needs to map it. Without it, sub-errors are serialized in the worker but silently dropped at the boundary — test.info().errors[0].errors will always be undefined at runtime even with the util.ts fix in place.

formatError in reporters/base.ts handles cause with a [cause]: ... prefix but doesn't iterate errors[], so sub-errors won't show up in terminal output.

packages/playwright/types/test.d.ts (TestInfoError) and packages/playwright/types/testReporter.d.ts (TestError) both need errors?: Array<T>, otherwise the field is invisible to TypeScript consumers even though the data is there at runtime.

docs/src/test-api/class-testinfoerror.md and docs/src/test-reporter-api/class-testerror.md each need a matching errors property entry (since: v1.61, same pattern as cause).

I went down the same rabbit hole and have all of it built out. Ping me if you want a hand — no pressure either way.

[dgozman]

@charliesheh Is this fixing an issue? Note that we require all non-trivial changes to have a corresponding issue.

[Zelys-DFKH]

Hey @charliesheh, looks like #40856 covers exactly this. Drop Fixes #40856 into the PR description and you should be good to go.