-
-
Notifications
You must be signed in to change notification settings - Fork 458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SetRequestInterceptionAsync(false) throwing TargetClosedException (Network.setCacheDisabled) #2693
Comments
using PuppeteerSharp;
var fetcher = new BrowserFetcher();
await fetcher.DownloadAsync();
await using var browser = await Puppeteer.LaunchAsync(
new LaunchOptions
{
Headless = true
});
await using var page = await browser.NewPageAsync();
await page.SetRequestInterceptionAsync(true);
async void HandleRequest(object? _, RequestEventArgs args)
{
try
{
await args.Request.ContinueAsync();
}
catch (Exception exception)
{
Console.WriteLine($"Error while intercepting request: {exception.Message}");
}
}
page.Request += HandleRequest;
try
{
await page.GoToAsync("[Site here]");
}
catch (NavigationException ex) when (ex.InnerException is TimeoutException)
{
// Ignore timeouts
}
page.Request -= HandleRequest;
await page.SetRequestInterceptionAsync(false);
Console.WriteLine("DONE"); Minimal reproducible code (it does require us configure an interceptor event), from what I can tell I cannot reproduce this in node: import puppeteer, { ExtensionTransport } from "puppeteer";
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on("request", (request) => {
try {
request.continue();
}
catch { }
});
try {
await page.goto("[site here]", { waitUntil: "networkidle0" });
} catch {
// Do nothing
}
page.removeAllListeners("request");
await page.setRequestInterception(false);
console.log("Done"); |
Hey! Sorry for the late response. Do you have any website to test? |
I'm seeing an error with the same setup. It started in v19.0.0 and did not happen in v18.1.0. It's also only happening on some domains. For example wbc(dot)co(dot)uk. It does not happen if I remove the interception code. An exception throws within GoToAsync:
|
Thank you for the example @Tiggerito. I'll take a look at it tomorrow! |
Fix is on the way |
I'm now seeing more detailed error messages:
I increased the timeout to see if that would help. Not really. The timeout is triggered when processing FrameManager.Client_MessageReceived. I don't see that code doing anything for 'Target.attachedToTarget', so I suspect it's waiting on the _frameTreeHandled.Task to complete in FrameManager.InitializeAsync, which happens to be called by FrameManager.OnAttachedToTarget when the target is an iframe. So it seems that FrameManager.InitializeAsync is sometimes taking a long time to complete the _frameTreeHandled task. |
@Tiggerito are you getting that on wbc? |
wbc? |
from here
|
Doh! It happens for multiple sites but is intermittent. i.e. I can't replicate it on my dev machine. I did see it happen a few times when I removed the interception code, so it may just increase the chances of it happening. It happens about 20 times a day, when it's crawling over 2,000 pages, so about 1%. wbc has been fine lately. I've increased the timeout to 5 seconds to see if it reduces the occurrences. |
We have a part of our application where we run interception, then disable it because it causes issues with
CSS.enable
via CDP.On some very specific sites, we're seeing a thrown exception during
await page.SetRequestInterceptionAsync(false);
, the exception is as follows:I can do something like this:
And as far as we can tell, this doesn't cause any issues, I don't know what is specifically causing this forced closed message, I haven't been able to reproduce a test site that reproduces the issue, but I can hand over the site that does if a dev wants to look at it.
Edit: Let me go putz with this in node and see if I just need to take this upstream.
The text was updated successfully, but these errors were encountered: