chrome-aws-lambda: [BUG] Navigation failed because browser has disconnected error for certain websites

@gsouf Spent the entire day around this, adding the following option to args seems to solve it:

--disable-features=AudioServiceOutOfProcess

Tested on 81.0.4044.0 (which will be published today hopefully).

My solution for anyone experiencing the same problem:

fix the chromium version to 79 by fix the module versions to :

• chrome-aws-lambda: 2.0.x
• puppeteer-core: 2.0.x
• puppeteer: 2.0.x

For me helped next actions:

• waitUntil: [‘load’, ‘networkidle0’, ‘networkidle2’]

• return await chromium.puppeteer.launch({ args: [ …chromium.args, ‘–disable-features=AudioServiceOutOfProcess’, ‘–disable-gpu’, ‘–disable-software-rasterize’, ] …

• use await where it’s need

• pupeteer has a limit of tabs, so I created a locker class and after 7 tabs close browser and open again.

• versions “@types/puppeteer”: “^2.0.1”, “@types/puppeteer-core”: “^5.4.0”, “puppeteer”: “^5.5.0”, “puppeteer-core”: “^5.5.0”,

Downgrating of pupeteer did’t helped for me, so it’s my solution.

@alixaxel you’re the boss thanks!

Also I don’t know if you noticed, an internal fix should come in chrome 83

Adding an abort on image and media requests allowed my lambda to complete successfully.

await page.setRequestInterception(true);

page.on('request', async(request) => {
  const requestType = request.resourceType();

  if (requestType === 'image' || requestType === 'media') {
    return request.abort();
  }

  return request.continue();
});

Glad to see you’re okay!

@14gasher I’m running with the following args and it works for me. Not really sure whether it will solve your problem but just for reference:

import chromium from 'chrome-aws-lambda'
...
await chromium.puppeteer.launch({
    args: [
        ...chromium.args,
        '--single-process',
    ],
})

browserPage.setContent is supposed to be async, maybe add a await keyword in front of it. s3Upload might also be an async function, hence it might also need the await keyword.

Also this issue does not seem to be directly related to chrome-aws-lambda and neither to this specific ticket, so if the issue persists after you tried to await the function then I would suggest that you try to get support from the puppeteer repository or on stackoverfklow using the tag puppeteer.

@alixaxel do you think you could package latest version of chromium with chrome-aws-lambda so that we can test if it solves.

If you don’t have time, can you explain how to do it please?

@gsouf @AlexisNava I had the same problem and adding await to browserPage.setContent fixed it! Thanks!

Recently was bit by this issue, workaround is to remove --single-process from the args passed:

    const args = chromium.args
    args.splice(args.indexOf('--single-process'), 1)
    return await chromium.puppeteer.launch({
        args,
        ...
    })

Unfortunately this doesn’t work on AWS Lambda, the browser does never start. @alixaxel Do you know of any way to make it work without --single-process? Thanks!

What about discarding media requests as a workaround? Something along the lines of

await page.setRequestInterception(true);
page.on('request', (req) => {
   if (req.resourceType() === 'Media') {
      req.abort();
   }
   else {
      req.continue();
   }
} 

@neekey Sorry it took a bit to follow up on this.

In all of these cases, the browser always crashes with:

[0405/032327.939344:FATAL:service.cc(56)] Check failed: !base::SystemMonitor::Get().

Related issues:

• https://github.com/puppeteer/puppeteer/issues/5487
• https://github.com/alixaxel/chrome-aws-lambda/issues/3#issuecomment-595825598
• https://github.com/alixaxel/chrome-aws-lambda/issues/39#issuecomment-589244053

What seems to be happening is Chromium is relying on additional processes for decoding audio/video, and since Lambda is single-threaded it ends up crashing. I’ll see what can be done to overcome this.

In all these cases, it seems to be related to audio and/or video being played on the page:

---

https://www.dailymotion.com/

Caused by dmp.main.e0d00292a4faa658874d.es5.js which plays the videos on the site.

---

https://www.arabnews.com/

The issue seems caused by sca.17.4.114.js, which uses the WebAudio API to fingerprint the device.

---

https://www.sayidaty.net/

Also caused by sca.17.4.114.js.

---

https://uae.sharafdg.com/

Caused by notif.mp3.

---

https://www.filmweb.pl/

@pgreda Caused by 765260af-5da5-4c5f-94ad-c2f0f5db7182.mp4.

---

https://toogoodtogo.nl/

Caused by life-of-bread.mp4 / life-of-bread.webm.

I just tried rolling back to 2.0.x for both puppeteer-core and chrome-aws-lambda, but I’m still getting the disconnect. Did any other flags need to be turned on / off?

My solution for anyone experiencing the same problem:

fix the chromium version to 79 by fix the module versions to :

• chrome-aws-lambda: 2.0.x
• puppeteer-core: 2.0.x
• puppeteer: 2.0.x

thank you for saving me the headache

i was using chrome-aws-lambda with latest versions as well and ran into the same problem using the 2.0.x versions fixed the problem of navigation crashes

€: I think this might have something to do with data cached within the lambda environment. Sometimes the chrome browser or page will crash immediately on retries but will work when I wait for 15 minutes between retries.