playwright
playwright copied to clipboard
[Feature] Prefer valid responses while routing from HAR files
Sometimes, HAR recordings of real traffic may have problems:
- network errors may occur when the connection is unstable
- client add-ons (such as adblocker) might abort HTTP requests
- server might be busy (503 response)
- and so on
When routing from har, given two har entries matching a request, I suggest we should always prefer valid responses (200) over things like "error aborted".
example for invalid response:
{
"startedDateTime": "2023-04-02T09:08:29.329Z",
"time": -1,
"request": {
......
},
"response": {
"status": 200,
"statusText": "OK",
"httpVersion": "HTTP/1.1",
"cookies": [],
"headers": [],
"content": {
"size": -1,
"mimeType": "x-unknown"
},
"headersSize": -1,
"bodySize": -1,
"redirectURL": "",
"_failureText": "net::ERR_ABORTED"
},
"cache": {},
"timings": { "send": -1, "wait": -1, "receive": -1 }
},
So when you generate your HAR file, you have a failing request and then a passing request. And then when you are actually using routeFromHAR the same behaviour gets replayed, am I understanding this correctly?
And the change is that instead of replaying it, filter out the aborted requests?
That's correct. Right now, Playwright always prefers the first response, so clients with a retry mechanism are stuck in an infinite loop. In cases where all of the matching requests are aborted, I don't think that filtering is such a good idea. But whenever there are several matches we can choose from, picking a valid response sounds better heuristics when compared to the current header-counting approach.
Ah alright, gotcha. TL:DR: we don't return in any order and always return the "bad" one if the first one was a "bad" one. Thanks for clarifying it!
Note to self: in a meeting we decided that it might be worth serving just last response if there are many. This will be the successful one if it was retried a few times.
Why was this issue closed?
Thank you for your involvement. This issue was closed due to limited engagement (upvotes/activity), lack of recent activity, and insufficient actionability. To maintain a manageable database, we prioritize issues based on these factors.
If you disagree with this closure, please open a new issue and reference this one. More support or clarity on its necessity may prompt a review. Your understanding and cooperation are appreciated.