trace CLI: request timing cannot be correlated with actions

[unlikelyzero]

Problem

When a test is flaky because of a race between a UI action and an in-flight network request, the answer should be derivable from playwright trace output: compare when the request was in flight with when the action ran. Today it isn't, for two reasons:

• trace requests prints only a duration for each request — no start time — while trace actions prints per-action start times. There is nothing on the request side to line up against the action clock.
• Failed and route.abort()ed requests never get an end recorded at all: the failure path leaves the HAR entry's time at its -1 default, so even the raw trace data cannot say when such a request stopped.

Proposal

• When tracing, record a duration for failed/aborted requests, derived from the entry's monotonic start stamp. User-exported HAR files keep the spec-defined value.
• Add a Start column to trace requests using the same clock and format as the trace actions Time column, and a matching start: line to trace request <id>.

With both in place, "was this request still outstanding when this action ran (or finished)?" becomes a plain timestamp comparison over CLI output.

[pavelfeldman]

"Pending" sounds quite broad. Could you help me understand what the issue is? My expectation is that coding agent would comfortably answer the "was this request still outstanding when this action ran (or finished)?" query.

[unlikelyzero]

Pavel Feldman (@pavelfeldman)

Fair — "pending" is doing too much work in that title.

An agent can't answer that from CLI output today: trace requests prints # / Method / Status / Name / Duration / Size / Route — no start time. trace actions prints a relative Time per action, but there's nothing on the request side to line it up against, so the overlap isn't derivable without dropping to the raw trace/HAR. The timestamp is already recorded (_monotonicTime on the HAR entry), it's just never surfaced.

The second half is that naive correlation gets it wrong even with the raw data: _computeHarEntryTotalTime only runs on response paths, so a failed or route.abort()ed request keeps time: -1. Treating that as "never finished" reports every aborted request as pending against every later action.

So I'd rather scope this down to: add a Start column to trace requests (relative to trace start, same format as trace actions), and make the unknown-duration case visible instead of it reading as a long request. That's enough for an agent to answer the question itself — which is your expectation, and I think you're right. Happy to drop the --pending / --pending-at flags.

[pavelfeldman]

Aligning the tool to produce consistent relative time makes sense to me.

[unlikelyzero]

Pavel Feldman (@pavelfeldman)

Yeah, fair. The agent can't actually do that today though: trace requests doesn't print start times, so there's nothing to compare against the actions table. And aborted/failed requests never get an end time recorded at all (time stays -1 on the failure path), so even the raw trace can't answer it for those.

I rewrote the issue around those two gaps and opened #42191 instead: adds a Start column to trace requests on the same clock as trace actions, and records a duration for failed requests. No new flags — with start times printed, the comparison is trivial like you said.