[Feature]: Stable lane index for reporter API

[vitalets]

🚀 Feature Request

I'm building a custom reporter that visualizes a Playwright test run as a timeline. To render it correctly, I need to place tests in the actual execution order and keep a stable lane per worker.

I tried using the current parallelIndex from the Reporter API, but it does not reflect the real worker lane layout when the number of active workers changes during the run.

Example

Consider the following setup with 4 test files:

spec1.test.ts // 1 test, passing
spec2.test.ts // 1 test, passing
spec3.test.ts // 1 test, passing
spec4.test.ts // 2 tests, both failing

Run on 4 workers (not in fully parallel mode), it produces the following visualization:

Two red spans are for failing tests from spec4. The second span gets parallelIndex = 0, so it is drawn on lane 1. But visually and logically, it belongs to lane 4, because it continues after the worker restart on that lane.

This creates a misleading picture of the run. For example, it makes the worker restart on lane 1 look like it took about 1s, while in reality it took only about 0.4s. As a result, the timeline becomes less reliable for analyzing scheduling and worker utilization.

Expected visualization:

Proposal

It seems there are a few possible ways to address this:

• Keep parallelIndex stable for the lifetime of a lane, even if the number of active workers decreases.
• Add a new laneIndex field that represents the actual visual/execution lane maintained by the Playwright runner.
• Add a new prevWorkerIndex or similar field that allows reporters to link a restarted worker to its previous lane.

Motivation

Stable lane index in the reporter API would make it much easier to build accurate timeline-style reporters.

[yury-s]

The current behavior is actually accurate. In your scenario it so happened that first 3 tests had already finished by the time spec4 failed, so when restarting it the runner picked the first available "lane" which had parallelIndex=0. If it had been still busy it would have picked a different one.