-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
UnhandledPromiseRejectionWarning: Error: Request is already handled! #5334
Comments
Same here, still waiting for a fix... |
Same here, still waiting for a fix...... |
I have the same issue |
Same |
Same, any update on this ? |
I have the same issue as well. I uninstalled all of my puppeteer-related packages and then reinstalled each and then it worked again for a short time. Then it stopped working again... ugh |
The package puppeteer-extra-plugin-block-resources is also failing with the same error. I can't find any way to block resources using the API directly. |
Hmm.. just started having this issue today. without changing any code. |
Same |
Happens to me too, anyone has any idea why? |
An answer was given here: #3853 |
const page = await browser.newPage(); then close() |
Hi, this is still an open issue. Puppeteer throws due to these lines:
Disabling these hot path assertions makes everything work perfectly. Why are these assertions even in the hot path? They seem like debugging code, or perhaps test code, that was left in production. Again, removing these assertions fixes everything ... so if they're not needed for everything to work, then please drop them from the src, as they're causing issues and are observably not required. |
@mathiasbynens perhaps you'd know why these assertions are here? Are they a performance boost? Can they be removed? Can we have devs add a flag to skip the assertions, resolving the issue? |
Seems like this approach only resolves the printing of logs not the issue itself |
@AliRafieePour in my dev env, commenting out the assertions allows the software to work as normal. I recommend removing them, which solves the problem of:
As far as I can tell, "Request already handled" should be be a debug warning for developers...not something that crashes a production instance. From that point of view...yeah...commenting out those lines is good enough to solve the issue ;) You're right, that we can say there are two issues here:
Personally, I only care about item 1, b/c it makes the software unstable. 2 can be solved at a later time, if it is an issue that causes stability issues outside of item 1. Triage |
I ended up doing something like this page.on("request", async (req) => {
try {
switch (await req.resourceType()) {
case "image":
case "stylesheet":
case "font":
await req.abort();
break;
default:
await req.continue();
break;
}
} catch (e) {
console.log(e);
}
}); you could probably get fancier, and create a store and check to make sure you're not trying to handle the same request. but for me ultimately i didn't care just wanted to "try" to abort some files if it could What's weird, and this is where it gets weird is, wrapping this in an async like this allows us to catch the underlying async throws even though these functions themselves are not promises/ async. not sure if that's the intended way to blanket catch under the hood async/promise errors but this seems to work... Edit: seems like something similar was already explained #3853 |
#3853 (comment) nails it |
I'm using puppeteer extra for ad and resource blocking, and I needed the "request" event for minor things (basically avoid the full page to load just to quickly push some existing state, like this). In my case, calling I noticed that I could do evil stuff, like collecting the old callback with It's just much simpler to create a page, remove the existing listener, do my stuff, close the page and start over. Maybe this workaround could help someone with a use case similar to mine. |
It works, but the problem occurs again when I deploy to firebase function. Is there any suggestion? |
For those who are facing this issue, it's happening when you assign a listener to the same event more than twice, so you want to do is either unsubscribe your listener once you're done with the listener's code execution and only then assign a new listener: function logRequest(interceptedRequest) {
console.log('A request was made:', interceptedRequest.url());
}
page.on('request', logRequest);
// Sometime later...
page.off('request', logRequest);
Otherwise, you always can create a new page and never unsubscribe the listener, it's up to you and to your use case, but the first option is preferable in the aspect of CPU/memory load minimization. |
Not sure why this works, but here is the solution that worked for me:
|
Not sure why too but it still working with puppeteer and puppeteer-extra with any plugins, TY! 🚀 |
Following the approach of @hatemjaber I create a function where realize this 'middleware' to me.
Just call this it with |
Puppeteer supports multiple request handlers. See here for more details: https://github.com/puppeteer/puppeteer/blob/main/docs/api.md#multiple-intercept-handlers-and-asynchronous-resolutions The tricky part was getting it working with puppeteer-extra. There is a long standing PR that adds support for it. berstend/puppeteer-extra#592 You can install that PR yourself, or use my fork where i built adblocker and puppeteer-extra plugins, if you'd like:
Then it becomes quite simple to solve: page.on('request', async req => {
const allowed = ...
if (allowed) {
// Only continue if it is not already handled (and thus blocked by adblocker)
if (req.isInterceptResolutionHandled()) {
await req.continue()
}
} else {
await req.abort()
}
}) Its been a painful day getting this working. |
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. |
The same error here as well.
Any further update on this issue please? |
Same error |
@ecmascriptguru @nxvinh222, I forgot how I resolved this error exactly but I think it was something like this:
You can add other types to the array other than |
I believe this was fixed by the cooperative interception mode: see https://pptr.dev/guides/request-interception In the legacy mode, a request abort/continue can only happen once and if it happens more than once the error is thrown. If that is the case, pls check your code and see if you (or puppeteer extension modules) register multiple event handlers. If you believe there is still a bug, please file a new report with a repro. |
Found the solution here Add this line: if (interceptedRequest.isInterceptResolutionHandled()) return; const puppeteer = require('puppeteer'); (async () => { |
1 similar comment
Found the solution here Add this line: if (interceptedRequest.isInterceptResolutionHandled()) return; const puppeteer = require('puppeteer'); (async () => { |
I trying use puppeteer to crawler but I have a problem when I call request to "Kick out login!". someone can help me!
thanks
`const puppeteer = require("puppeteer");
( async () => {
const browser = await puppeteer.launch()
const page = await browser.newPage()
await page.setRequestInterception(true)
await page.setUserAgent(process.env.USER_AGENT)
})()`
The text was updated successfully, but these errors were encountered: