PLAYWRIGHT CLI · CHECKED OCTOBER 15, 2026
Line 3 happened before line 2.
A network file is an evidence source. Its physical line order is not necessarily the order in which requests started.
The retry fixture makes one verification request that receives 503, then another that receives 200. In the captured network file, the successful request appears on physical line 2 and the earlier failed request appears on line 3. Sorting the records by their native monotonic start clock recovers the observed start sequence while retaining each original line reference.
Do not collapse repeated requests
| View | What it retains | What it loses |
|---|---|---|
| Unique URL set | The endpoint was observed | How many attempts and their outcomes |
| Request count | Two occurrences | Whether they were 200 → 503 or 503 → 200 |
| Ordered occurrence list | Method, status and source for each request | Still does not prove why an attempt happened |
TracePair preserves both occurrences even when their raw URLs match exactly. The endpoint alias is shared; the two request rows remain distinct. The endpoint summary shows 503 → 200, and the full interval sequence preserves any other endpoint requests interleaved between them.
Walk through the native example
- Load One success / a retry on the comparison page.
- Review the action pairs and select the click interval.
- In B, inspect the 503 row and then the 200 row. Their source references are line 3 and line 2, respectively.
- Open the endpoint summary. A has one GET 200; B has GET 503 followed by GET 200.
- Export the interval. The export keeps the source line and monotonic start of each occurrence, so another reviewer can check the order.
Download the reduced retry network file. Compare it with the reference network file. The samples come from a controlled local fixture, not a customer trace.
Equal timestamps are an uncertainty
Two requests can share the same recorded monotonic time. We display those in physical source-line order to make the output stable, but this is a tie-breaker, not evidence of a strict start order. An interval with tied timestamps is flagged. If the apparent sequence difference depends on that tie, read it as an order review, not a confirmed reversal.
Absolute wall-clock dates are not substituted for missing monotonic clocks. Captures can have different wall-clock origins, and those clocks can move. TracePair refuses network records without a usable non-negative monotonic start. Zero is valid; it is not treated as a missing value.
A retry can be intentional
The fixture explicitly retries a failed response. A production application may retry due to a client policy, a user action, a service worker, or another source. The trace records observations. It does not encode your intended retry budget or prove that the selected click caused each request. Check the application policy, then repeat a controlled test. Do not calculate a meaningful p95 or failure percentage from these two captures.
Keep the final interval open through all remaining supplied request records. Ending it at the final action end would silently discard a late background request. Unattributed requests and requests before the first anchor stay in a separate, exported bucket.