Comments (10)
Usually this error happens when you try to access a response body of a request which was from a previous navigation. Browsers like Chromium will clean them up from their memory in order to save memory and give you this error. What might work is the following:
import { test, expect } from '@playwright/test';
for (let i = 0; i < 10; i++) {
test(`demo JSON + ${i}`, async ({ page }) => {
let resolveResponse = null;
const waitForSpecificResponse = new Promise(resolve => resolveResponse = resolve);
page.on('response', async response => {
if (response.url().includes('feed_content?'))
resolveResponse(await response.json());
});
await page.goto('https://dev.to/playwright');
const responseBody = await waitForSpecificResponse;
const totalCount = responseBody['result'].length;
expect(totalCount).toBeGreaterThan(0);
});
}
Alternatively try to delay the second navigation if possible.
from playwright.
I know about page.route -> but I don't know if I can use it in the context of listening and possibly returning data later on
Yes, you can. See this document: https://playwright.dev/docs/release-notes#response-interception You can fetch response, analyze it and then fulfill original request with it. Does this work for you?
from playwright.
The example linked is a modification of the request, and in my case:
- I know that when the page loads there is a request that has JSON in the body. And after the page loads, it wants to use the data in JSON to look for elements on the page by selectors. (It does not want to do this asseration in the body of the page.route function).
from playwright.
Can you explain then what is not working for your scenario in the following code?
const responsePromise = page.waitForResponse('**/dataRequest.json');
await page.goto('/');
const response = await responsePromise;
const data = await response.json();
expect(data).toBeTruthy();
// analyze the data and interact with the page
from playwright.
Assertion is unstable because I am checking a request that has quite a large body - And playwright sometimes pulls it out too βfastβ as the JSON is unprocessed.
from playwright.
I rewrote the function that listens for requests and noticed that the tests work a little better (the ones that wait for requests). But I have a feeling that I'm not doing it optimally.
Just as I described waitForRequest
itself, it doesn't wait for the body to be processed to the end in my case.
export async function interceptResponse(searchString: string, page: Page) {
const response = page.waitForResponse(
(response) =>
response.url().includes(searchString) &&
response.status() === 200 &&
response.body() !== null &&
response.request().failure() === null,
{ timeout: 30000 },
);
return response;
}
from playwright.
And playwright sometimes pulls it out too βfastβ as the JSON is unprocessed.
could you elaborate on that?
We need a reproduction which we can run locally in order to act on issues like that. Most likely there is a race somewhere, so looking at code is essential for us. Would it be possible to share a small test, ideally with expected and actual outcome?
from playwright.
It's hard for me to find an adequate JSON example(Our JSON loads within half a second as part of the page opening.), and unfortunately, I can't share a real example, but it is very similar to the example below.
import { test, expect } from '@playwright/test';
for (let i = 0; i < 10; i++) {
test(`demo JSON + ${ i}`, async ({ page }) => {
let promise = page.waitForResponse(
(response) =>
response.url().includes('feed_content?') &&
response.status() === 200 &&
response.body() !== null &&
response.request().failure() === null,
{ timeout: 30000 },
);
await page.goto('https://dev.to/playwright');
const response = await promise;
const responseBody = JSON.parse(await response.text());
let totalCount = responseBody["result"].length;
expect(totalCount).toBeGreaterThan(0);
});
}
I looped the test to try to induce instability described as a topic of this task, but it works stably here.
Test in my case is failing at const responseBody = JSON.parse(await response.text());
.
Once I try review trace (in case of test failing due instability) with to check request body in network tab I can see:
This test passes completely randomly, depending on whether the body manages to generate in time
from playwright.
This solution works, but requires some refactoring on the side of my tests. As if there would be a dedicated function which one handle request in expected way in playwright for this I would be happy.
from playwright.
Closing as the problem has been resolved and there are no planned changes on playwright side.
from playwright.
Related Issues (20)
- [Bug]: .env file bypassed in debug mode 1.1.1 HOT 2
- [Feature]: Trace viewer: When using multiple browsers, I would like to see which browser is making which HTTP request HOT 1
- Video testing is not working on playwright HOT 4
- [Bug]: JUnit report contains invalid character in logs HOT 2
- [Bug]: Running issues in debug does not work and ends up in multiple different situations. HOT 4
- [Bug]: 1.44.0 automatically closes the browser on test end (even with reuseBrower:true) HOT 2
- Can't run tests in debug mode HOT 11
- [Bug]: Test info attached in html report in wrong format HOT 1
- [Feature]: receive parameters in `test.describe()` HOT 1
- Target page, context or browser has been closed HOT 1
- [Bug]: Unable to view the right context on Traces and Videos
- [Bug]: Playwright Extension Test Explorer cannot find setup.ts files HOT 2
- [Bug]: Updated to Playwright Test for VSCode v1.1.1 and all test except one dissappeared from Test Explorer view HOT 2
- [Bug]: Can't run tests with the extension (no Browser will be opend) HOT 3
- [Bug]: Setting a different locale does not work as expected HOT 4
- [Regression]: Playwright Test for VSCode can't find *.spec.ts files HOT 8
- [Bug]: "waitForResponse" always fails on firefox HOT 1
- [Bug]: Using force:true to click on an element overlapped by another element will not click or error out HOT 1
- [Bug]: Using test.fail() does not actually fail the test HOT 2
- [Bug]: Locators are in Playwright provided is not Detecting when we run same Scripts again HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from playwright.