TargetCloseError: Protocol error (Page.printToPDF): Target closed

[robgaskell]

Since upgrading to version > 1.9.1 we have frequently been getting one of the following exceptions when attempting to generate PDF's using the package:

Error: Command failed: node ./browser.cjs '-f file:///tmp/browsershot.js' TargetCloseError: Protocol error (Page.printToPDF): Target closed at CallbackRegistry.clear (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:146:36)

Error: Command failed: node ./browser.cjs '-f file:///tmp/browsershot.js' ProtocolError: Page.printToPDF timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed. at <instance_members_initializer> (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:49:14)

I have since downgraded back to v1.9.1 and the exceptions have all stopped happening.

Any idea what could be causing these problems and how to overcome them?

I have tried to find and configure the protocolTimeout setting as suggested in the exception message but I couldn't find any information to help with this, so either my attempts to set it were wrong or were unsuccessful as a solution as whatever I tried made no difference to the outcome.

[stefanzweifel]

Thanks for reporting @robgaskell.

From my point of view, I don't really know how I should reproduce this error on my side.
Can you tell us, how many PDF pages you're generating.

The error message would suggest to me, that you might create PDFs with "thousands" of pages or that sidecar-browsershot or AWS Lambda has some garbage collection issue, where "old" instances linger around and break the browser.

A quick search for "protocolTimeout" revealed the following links:

• [Bug]: ProtocolError: Target.createTarget timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.  puppeteer/puppeteer#10144 (comment)
• Increasing protocolTimeout? spatie/browsershot#760

The upstream spatie/browsershot package doesn't support setting protocolTimeout – as far as I can see – therefore sidecar-browsershot also doesn't support this.
But that's something that could be contributed to spatie/browsershot.

Here's also the relevant docs for puppetteer: https://pptr.dev/api/puppeteer.browserconnectoptions/

[robgaskell]

Thank you for your reply.

I have a report that I am using for testing which is typical for the kind of PDF's we need to produce. This report has a html source of approx 14MB and when it does generate the PDF (using v1.9.1) it is 159 pages, primarily made up of a large table.

I am aware that Chrome is not particularly fast at rendering table data. However the report does consistently generate correctly under v1.9.1 and fails in more recent versions.

I wonder if the default settings for Chrome changed with the changing of the layer in #85

Thank you for the links you supplied, I will have a read through these.

[stefanzweifel]

@robgaskell Will add some tests for this in the next few days to hopefully reproduce this issue.

I wonder if the default settings for Chrome changed with the changing of the layer in #85

#85 was quite the version jump. I think we went from v104 to v116. Could well be that something has been updated internally inside of Chrome.

[stefanzweifel]

I was finally able to reproduce this issue.

I generated an enormous 20 MB HTML file and used that the source of the Browsershot request. Here's my code.

BrowsershotLambda::readHtmlFromS3('example-read-from.html')
    ->timeout(300)
    ->save('example.pdf');

This resulted in the same error you got @robgaskell.

Lambda Execution Exception for Wnx\SidecarBrowsershot\Functions\BrowsershotFunction: "Command failed: node ./browser.cjs '-f file:///tmp/browsershot.js'
ProtocolError: Page.printToPDF timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed.
    at <instance_members_initializer> (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:49:14)
    at new Callback (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:53:16)
    at CallbackRegistry.create (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:93:26)
    at Connection._rawSend (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:215:26)
    at CDPSessionImpl.send (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:465:33)
    at CDPPage.createPDFStream (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Page.js:870:50)
    at CDPPage.pdf (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Page.js:896:37)
    at getOutput (/var/task/browser.cjs:59:40)
    at callChrome (/var/task/browser.cjs:377:24)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
. [TRACE] Error: Command failed: node ./browser.cjs '-f file:///tmp/browsershot.js' ProtocolError: Page.printToPDF timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed. at <instance_members_initializer> (/opt/nodejs/node_modules/puppeteer-core/lib/cjs/puppeteer/common/Connection.js:49:14)".

As you mentioned, Puppeteer itself suggests increasing protocolTimeout.
protocolTimeout is part of the BrowserConnectOptions-interface and has a default value of 180_000 (I assume the value is in milliseconds which would equal to 3 minutes)

spatie/browsershot does not have a dedicated protocolTimeout-method yet. But it exposes setOptions() which allows us to set the option anyway.

BrowsershotLambda::readHtmlFromS3('example-read-from.html')
    ->timeout(300)
    ->setOption('protocolTimeout', 600_000)
    ->save('example.pdf');

However, I get the same error message after using setOption. Currently trying to debug, if the option is set and passed correctly to Chromium.

[stefanzweifel]

The protocolTimeout setting is definitely being passed to Chromium. This is a dump of the options passed to Chromium:

{
  path: '/tmp/browsershot',
  args: [
    '--allow-pre-commit-input',
    '--disable-background-networking',
    '--disable-background-timer-throttling',
    '--disable-backgrounding-occluded-windows',
    '--disable-breakpad',
    '--disable-client-side-phishing-detection',
    '--disable-component-extensions-with-background-pages',
    '--disable-component-update',
    '--disable-default-apps',
    '--disable-dev-shm-usage',
    '--disable-extensions',
    '--disable-hang-monitor',
    '--disable-ipc-flooding-protection',
    '--disable-popup-blocking',
    '--disable-prompt-on-repost',
    '--disable-renderer-backgrounding',
    '--disable-sync',
    '--enable-automation',
    '--enable-blink-features=IdleDetection',
    '--export-tagged-pdf',
    '--force-color-profile=srgb',
    '--metrics-recording-only',
    '--no-first-run',
    '--password-store=basic',
    '--use-mock-keychain',
    '--disable-domain-reliability',
    '--disable-print-preview',
    '--disable-speech-api',
    '--disk-cache-size=33554432',
    '--mute-audio',
    '--no-default-browser-check',
    '--no-pings',
    '--single-process',
    '--disable-features=Translate,BackForwardCache,AcceptCHFrame,MediaRouter,OptimizationHints,AudioServiceOutOfProcess,IsolateOrigins,site-per-process',
    '--enable-features=NetworkServiceInProcess2,SharedArrayBuffer',
    '--hide-scrollbars',
    '--ignore-gpu-blocklist',
    '--in-process-gpu',
    '--window-size=1920,1080',
    '--disable-webgl',
    '--allow-running-insecure-content',
    '--disable-setuid-sandbox',
    '--disable-site-isolation-trials',
    '--disable-web-security',
    '--no-sandbox',
    '--no-zygote',
    '--headless'
  ],
  viewport: { width: 800, height: 600 },
  s3Source: {
    path: 'example-read-from.html',
    region: 'us-east-2',
    bucket: 'sidecar-us-east-2-xxxxxxxxx'
  },
  timeout: 300000,
  protocolTimeout: 300000000,
  executablePath: '/tmp/chromium'
}

Now I wonder if this is a bug in Chromium or we're doing something wrong.

[drfraker]

FWIW Updating browsershot to ^4.0 and sidecar-browsershot to ^2.0 seems to have fixed this "Target closed" issue for us.

[stefanzweifel]

Thanks for the update @drfraker.
Will give this a try in my demo-app as well and report back.

[tominal]

FWIW Updating browsershot to ^4.0 and sidecar-browsershot to ^2.0 seems to have fixed this "Target closed" issue for us.

This worked! Thank you @drfraker

[robgaskell]

Agreed, upgrading to the latest release has fixed this issue for us too. Thanks