Protocol error (Target.createTarget): Target closed. #1947
Comments
|
I've also encountered this error. |
|
@GregRos which version of puppeteer are you using that you also see this in? |
|
We are now up to 48 of these over ~6000 requests. |
|
Can you post the stack trace along with the error? The only usage of |
|
|
Anything else I can provide to help you trace this? We've had another 21 failures in the the last 7 days alone over an additional ~2000 requests. The error rate seems variable. The code is as you see, we don't interact with puppeteer anywhere else on this server, so I don't see how we could be calling |
|
Over the last 60 days, out of ~17,000 requests exactly 376 have triggered this failure scenario, about a 2% failure rate. Still hoping for some insight into if this is a puppeteer issue or something on our end. |
|
Faced with |
|
Not sure if this helps anyone, but I had the issue while running it with aws lambdas. For me it solved the issue that I made sure I closed the chrome properly via |
|
Did anyone figure out a work around? I cannot use |
|
This would definitely happen if you were calling It is unlikely that these problems are related. It would be very helpful if someone could send a script I can run that reproduces this problem. |
|
@mxab thank you, I was also able to fix this error (running on an AWS Lambda) by adding a call |
unfortunately await all page.close() didn't eradicate this problem or even help it in my case. |
|
This is very dependent on what environment you run in. |
…teer protocol failures (did not seem to affect functionality), see: puppeteer/puppeteer#1947
|
I am still facing this, even with browser.close. |
This was exactly my problem on Lambdas. Thanks a lot @JoelEinbinder |
|
From my experiments it seems this is caused by the same glibc bug as #2207 (https://sourceware.org/bugzilla/show_bug.cgi?id=19329). |
…3540) #### Description of changes This was originally motivated by wanting to audit all the `browser.close` instances to see if we were ever closing a browser while there might still be an unawaited page.close in progress, which per [this puppeteer issue](puppeteer/puppeteer#1947) might explain [failures like what we're seeing in the e2e windows jobs here](https://dev.azure.com/accessibility-insights/accessibility-insights-web/_build/results?buildId=15197&view=results). I didn't find anything to suggest that that's an accurate root cause for our issue, but I thought this update made stuff more readable regardless. #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [n/a] Addresses an existing issue: #0000 - [x] Ran `yarn fastpass` - [n/a] Added/updated relevant unit test(s) (and ran `yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] PR title *AND* final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`). See `CONTRIBUTING.md`. - [n/a] (UI changes only) Added screenshots/GIFs to description above - [n/a] (UI changes only) Verified usability with NVDA/JAWS
Yep, only getting this in pipe mode |
|
What worked for me, as the number of requests grew in size, was to split the requests into different functions and executing those functions asynchronously: const scrape1 = async () => {...}
const scrape2 = async () => {...}
const run = async () => {
await scrape1()
await scrape2()
}
run() |
I also tried this - I am using chrome-aws-lambda. Didn’t work that way. |
|
This will happen if Chromium doesn't have enough memory on startup. I was running You might get away with allocating less than 1024MB, but I haven't tried. |
That's interesting! I am running all my pdf-lambda functions on 3008 MB ever since, so that doesn‘t work for me. |
I'm still having the same issue. its surely not an issue with the code I tried to run the same code on another machine it worked fine I'm running |
This comment has been minimized.
This comment has been minimized.
|
oh thanks ill look in to it i manage to fix the issue by mentioning chrome path and using puppeteer-lite. I will this again! |
|
For those that are on heroku and ruby/rails, make sure to disable I've been hit by this and has dug so deep until I saw that another developer decided to just test out all his buildpacks: Ref: Studiosity/grover#80 |
|
Has anyone been able to get I'm also seeing this error: |
|
Same pb here @davidbielik |
|
I'm getting the same issues on M1 Mac, same code works fine on Windows 10 This seems related to docker/for-mac#5123 |
|
Same problem with browser.newPage() running docker on an M1 machine. |
|
@marcelpanse i opened #7916, I'm having the same problem. |
thanks man you saved me |
|
I am on Apple M1, closing every single page before closing the browser worked for me. See #1947 (comment). |
|
I am on centos，using 'browser.createIncognitoBrowserContext().newPage();'. i am having the same problem. using 'browser.newPage()' is worked for me. |
|
For me, the M1 problem was that my container's image only supports To anyone encountering the issue on M1, you can run |
Hi @JonathanGuo |
The image I built is based on alpine. What I've done was just rebuild the image on an arm64 platform. Since the image I built is the base image that needs to support multiple platforms, I have added and pushed the manifest. You can use Hope this is helpful. |
|
This solved our problem with development on PC and M1 mac. |
|
@tapiau solution worked for me. |
|
Hello, for me I had to close the extensions before the browser like this. |
|
Guys, can anyone help here, I'm stuck on running test in persistent context, and problem is when running tests in workers, where we preserve state per worker. Single test run works fine, but any other test added fails with:
and this is my configuration in fixture: |
|
i got the same. I read some people had more luck going to v16, so i did but now i get other errors: Sep 10 14:53:50Z sr-bot app/web.1 [Nest] 20 - 09/10/2023, 2:53:49 PM ERROR [ExceptionHandler] Failed to launch the browser process! Frustrating that it works locally but not on heroku :( |
|
I still have this issue. In my case the error is thrown by .pdf() function. I described the problem on stackoverflow. |
and others
Steps to reproduce
Tell us about your environment:
What steps will reproduce the problem?
Very random and rare. Out of over 2500 requests, we have 20 of these failures.
Please include code that reproduces the issue.
html is just a bunch of ejs rendered html.
What is the expected result?
No protocol error
What happens instead?
Randomly returns
Protocol error (Target.createTarget): Target closed.The text was updated successfully, but these errors were encountered: