fix(har): do not hang when response extra info never arrives - #42450
fix(har): do not hang when response extra info never arrives#42450Ashraf Ali (ashrafiucse) wants to merge 3 commits into
Conversation
Chromium may advertise `hasExtraInfo` on a response and then never deliver the extra info, or stop reporting the request at all after responseReceived. Two changes make this survivable: - when the request finishes without extra info for some of its responses, resolve their raw header promises with the provisional headers, in the same way as for responses without the extra info flag; - when the HAR recording stops, drop the pending raw header upgrade barriers instead of waiting for them - provisional headers are already recorded as a fallback for exactly this case. Fixes: microsoft#42448
|
@microsoft-github-policy-service agree |
| } | ||
|
|
||
| // We are not done yet. | ||
| // The request is over, so no more extra info can arrive for it. Fall back to |
There was a problem hiding this comment.
that's not necessarily true as responseReceivedExtraInfo can come later so please undo this change
There was a problem hiding this comment.
Undone in 2148b48 — nothing is force-resolved on the server side anymore.
The hang is now fixed entirely on the tracer side (70ff634): when the recording stops, HarTracer.flush() drops the still-pending barriers that only upgrade already-recorded provisional data (raw headers, sizes, compression). This is still needed because BrowserContext.close() flushes the HAR before the pages are closed, so those barriers would otherwise wait for the extra info forever, e.g. when loadingFinished arrives without responseReceivedExtraInfo.
Verified with the repro from the issue in all three modes (extra info withheld / loadingFinished withheld / both) — context.close() completes in each.
Test results for "MCP"2 failed 8257 passed, 1361 skipped Merge workflow run. |
Test results for "tests 1"7 flaky51258 passed, 1244 skipped Merge workflow run. |
Revert the eager resolution of pending responses with provisional headers when a request finishes: responseReceivedExtraInfo can still arrive after loadingFinished. The HarTracer flush() change alone is enough to avoid hanging, as provisional headers are recorded as a fallback. Fixes: microsoft#42450 (review)
With the response extra info never arriving, the request can still finish normally (Network.loadingFinished is delivered). The HAR tracer then adds sizes and compression calculation barriers that await the extra-info-fed response headers size promise, which never resolves. Since tracing flush runs before the pages are closed, these barriers hang context.close() the same way the raw header barriers did. Treat all barriers that only upgrade already-recorded provisional data as droppable on flush, not just the raw header ones. The extra info is not force-resolved server side because it can still arrive after loadingFinished. Fixes: microsoft#42448
|
Let's start with figuring out the problem and usecase first. We can reopen this PR once the issue is clear. |
3 participants
Summary
responseReceivedExtraInfocan still arrive afterloadingFinishedhar.spec.tsthat withholdNetwork.responseReceivedExtraInfo/Network.loadingFinishedfor a single request via a CDP websocket proxy (both hang without the fix)Fixes #42448