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)
- [Feature]: Support optGroup parameter in Locator.selectOption method HOT 5
- [Feature]: get and set radiogroup value
- Contribute new matcher
- [Bug]: --ui mode doesn't respect --trace as of 1.43 HOT 5
- [Bug]: Playwright Extension versions 1.1.1 to 1.1.6 cannot see tests in test files HOT 1
- [Bug]: component tests fail with cryptic error when files are moved around HOT 1
- [Bug]: Linux WebKit missing support for WebRTC
- [Docs]: Clarify WebKit Feature Support on Non-Apple Platforms HOT 1
- [Bug]: context.pages is not being updated with newly opened tabs HOT 3
- [Bug]: Attribute resolved to 2 elements HOT 1
- [Bug]: `create-playwright` doesn't show a version number HOT 4
- [Bug]: `create-playwright` adds duplicate .gitignore entries HOT 2
- [Bug]: `create-playwright` doesn't exclude `playwright-report` in `tsconfig.json`, leading to type errors HOT 2
- [Bug]: Results from UI mode are not merged with merge reports command HOT 2
- [Docs]: PW API documentation - Add more details and example section for multipart/formData request HOT 2
- [Bug]: Screenshot masking not working for fullpage since 1.44
- Playwright with NUnit (c#) does not have soft assert HOT 1
- [Bug]: Cannot get project name with VSCode extension 1.1.1-1.1.6 HOT 1
- [Bug]: (regression) VSCode Extension only detects testDir from one project HOT 4
- [Bug]: page.screenshot failed HOT 3
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.