Request interception hanging forever #7475
Comments
|
Went through the CDP messages and have some more info: Whenever a request hangs, there are two Notice the different request ids: I'm not sure if this is an issue with |
|
This issue doesn't occur when caching is disabled via Ah, it seems like there is a corresponding CR bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1196004 . The mentioned |
|
Just went through a bunch of different puppeteer versions and weirdly the issue starts to occur for me starting with |
|
The fix landed in |
|
I can't reproduce the issue with the following environment:
I'm using the script provided |
|
v10.2.0 broke the |
|
This bug is still present on v11.0.0 |
|
@mmoutonn Can you send some code to repro the issue? |
@Androbin Do you have a link to the exact PR that fixed this issue? |
|
The issue of request interception with caching failing when loading stylesheet-initiated fonts was fixed in #7060, accompanied by a unit test. If you can modify the unit test to be failing again, I'd be happy to take a look. Also see #7038 @starrify for an excellent analysis of the underlying issue. |
|
Noticing similar issue in
Requests to fetch fonts from the CDN never completes and eventually page.goto hits timeout duration. |
|
Have the same issue. After some debugging, it seems to be only hanging for certain URLs and in headful mode. In my case, Debug logsHeadful modeHeadless modeEnvironmentScript to reproduce the issueconst puppeteer = require('puppeteer');
(async () => {
const browser = await puppeteer.launch({ headless: false });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on('request', (interceptedRequest) => {
interceptedRequest.continue();
});
await page.goto('https://www.google.com');
await browser.close();
})();WorkaroundReverting back to Puppeteer 9.1.1 |
|
@benallfree I'm also having issues with puppeteer 10.0.2 where it hangs until the timeout. reverting back to 10.0.1 doesn't have the problem. I pinpointed it to the cooperative requests PR, however, I haven't figured out exactly why it's breaking my code as I only have one request interceptor. Our codebase is very large so it might take a bit to figure out a basic repro scenario, but I can definitely confirm that 10.0.2 does indeed break our codebase and 10.0.1 does NOT. |
|
@razorman8669 Do you mean 10.2.0? Cooperative requests didn't land til 10.2.0, so if you are seeing an issue on earlier versions (10.0.2/10.0.1) it likely is not related. If you can get a snippet to repro that would be super helpful. In the mean time, I'll use the original snippet in this ticket and see if I can repro it on |
|
Yes, i meant 10.2.0 (not 10.0.2). Sorry for the confusion |
|
@atikenny I confirm the same thing exactly. @razorman8669 Definitely not related to #6735. According to Bad commit: f863f4b Changing from Chromium All you have to do in f863f4b is update export const PUPPETEER_REVISIONS: Revisions = {
chromium: '884014', // BAD
firefox: 'latest',
}; |
|
Update for everyone - The issue is The way NetworkManger is written, it assumes a 1:1 interaction between the two events, but that is not true. See #7038 (comment),. I think #6996 (comment) has introduced some complexity, looking into it further. |
In my case we are seeing CORS issue while trying to fetch the fonts. Even if this request fails, pdf should be generated with some other fallback font. request interception + caching disabled -- Successfully generates a PDF request interception + caching enabled -- page.goto timeout error |
|
I have a PR started to address this issue. Please test it if you can #7802. |
|
Issue still reproduces consistently on my end with puppeteer v13.0.1 while working fine when reverted back to v10.1.0 |
|
I've noticed that |
|
@dekelev I'm the author of |
|
I agree, though it seems to require adding specific support for it in puppeteer-extra plugins, which I was trying to avoid. I guess I would have to fork these plugins since this issue doesn't seems to bother the author of those libs. |
|
@dekelev I'd get in contact with |
|
Awesome, thanks! |
|
I can still reproduce this on puppeteer version 14. Working on a minimal reproduction… |
|
Here you go. It worked until puppeteer v9, and broke in v10: https://github.com/rudolfbyker/puppeteer-issue-7475-reproduction |
|
@rudolfbyker it’s probable you’re experiencing an underlying CDP bug, not something in Puppeteer or higher level libraries. Please check out this and related tickets for more details. The minimal example you posted is actually quite a bit larger than the minimal examples needed to repro the CDP bug. I’m not able to dig into it further at this time, but I wanted to drop a note in case you had time to research the possibility that you’re experiencing a CDP bug. |
What's CDP? Do you have a link so I can learn more?
Is there something else I should update / fix / make a repro for?
Which tickets? Do you have a link?
Much appreciated. |
|
We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days. |
|
Not stale, because I'm waiting for response from @benallfree :) |
|
I can confirm the problem persists. |
|
So it seems only the repro from #7475 (comment) is reproducible with the current version of Puppeteer. It does look like another instance of double pause events sent by the backend. It does not lead to indefinite hanging for page.goto though. |
font request interception caching might trigger a double requestPaused CDP event which triggers "request" Puppeteer event to be emitted twice which breaks tracking of in-flight requests. See https://bugs.chromium.org/p/chromium/issues/detail?id=1196004 and puppeteer/puppeteer#7475.
|
I still see this issue with latest, v19.8.3 |
|
I am not able to repro #7475 (comment) with v20.2.1 |
|
Just encountered this issue with: Pptr: 20.8.0 Using waitForRequest() works, the correct url is being intercepted and the intercepted request is paused and is interactable. Edit: edit2: It is! Interception and continuation do work properly using the Fetch Domain. With the version Im using, at least. |
|
puppeteer/packages/puppeteer-core/src/api/Page.ts Lines 604 to 634 in a71c62f I had log out all these event ( on request start and finish ), and found that A different request.id="interception-job-8.0" appeared on Pptr: 22.6.1 |
|
@deemstone do you have a minimal reproducible example or a CDP log? If the browser is not sending the fail or success events, we should report it to crbug.com |
Steps to reproduce
Tell us about your environment:
What steps will reproduce the problem?
The issue can be reproduced with the following snippet:
Note: When run in headful mode via
devtools: trueit fails not as consistently anymore, but still fails from time to time.From the past hours debugging this, it seems to be caused by a font-face request pending forever. This issue seems similar to #6696 .
What is the expected result?
Requests should not hang.
What happens instead?
A request for a font never resolves, which leads to the
loadevent never being fired. This leads to puppeteer throwing a timeout error.The text was updated successfully, but these errors were encountered: