playwright icon indicating copy to clipboard operation
playwright copied to clipboard

[Feature] Prefer valid responses while routing from HAR files

Open NoamGaash opened this issue 2 years ago • 4 comments

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 }
      },

NoamGaash avatar Apr 11 '23 07:04 NoamGaash

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?

mxschmitt avatar Apr 11 '23 17:04 mxschmitt

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.

NoamGaash avatar Apr 13 '23 12:04 NoamGaash

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!

mxschmitt avatar Apr 13 '23 13:04 mxschmitt

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.

yury-s avatar May 05 '23 18:05 yury-s

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.

pavelfeldman avatar Apr 22 '24 17:04 pavelfeldman