Protocol error (Page.printToPDF): Target closed.
-
@jan_blaha I upgraded to 2.5.0 yesterday and very quickly discovered this issue, I just tried downgrading Puppeteer to 1.11.0 as you suggested but it makes no difference - I will have to backdate to 2.4.0 for the time being, pitty as the new editor is much better
-
Are you sure you have downgraded puppeteer successfully?
Run the template with debug button, you should seeConverting with chrome HeadlessChrome/72.0.3618.0 using dedicated-process strategy
I don't think there is something in jsreport 2.5.0 that could make it failing like this except different chrome version.
-
@jan_blaha Hmm, I dont see that Chrome version, I see
+21803 Executing recipe chrome-pdf
+22078 Converting with chrome HeadlessChrome/73.0.3683.103 using dedicated-process strategy
+24096 Running chrome with params {"printBackground":true,"margin":{}}
Error: Protocol error (Page.printToPDF): Target closed.
at Promise (/app/node_modules/puppeteer/lib/Connection.js:186:56)
at new Promise (<anonymous>)
at CDPSession.send (/app/node_modules/puppeteer/lib/Connection.js:185:12)
at Page.pdf (/app/node_modules/puppeteer/lib/Page.js:911:39)
at Page.<anonymous> (/app/node_modules/puppeteer/lib/helper.js:145:23)
at runWithTimeout (/app/node_modules/jsreport-chrome-pdf/lib/conversion.js:164:27)
at <anonymous>
at process._tickDomainCallback (internal/process/next_tick.js:229:7)However if bash into my Docker image locally and do a
cat node_modules/puppeteer/package.json
it shows
"version": "1.11.0"
There must be more to downgrading Chrome than puppeteer - forgive me I know very little about how Chrome works with puppeteer or even what puppeteer is (perhaps I should Google that :) )
Cheers
-
Ah ok, you use docker. The docker doesn't use the chrome installed through puppeteer because that one doesn't work in the headless docker environment.
See how the chrome is installed in the 2.4.0 version
https://github.com/jsreport/jsreport/blob/2.4.0/docker/default/DockerfileIt would help us a lot if you would prepare for us a replicable demo. We will be releasing in the next days jsreport 2.6.0 and it would be great if we can test if your issue is resolved there before we ship it.
-
@jan_blaha
Thanks for your quick responses :)So we use JsReport a little differently to normal case I think, our Request Data (or sample Data) contains URLS of where to get the actual data from, the reports JS file will fetch the data and populate the Request.data context for the template to iterate over.
However this does not seem to be the problem as I was able to reproduce the error within our Docker test environment with just a Template and a large sample Data file (2000 records) side stepping the JS file altogether, reducing the sample Data to 1000 records and it runs fine - I have not found the breaking point
But when I copied these 2 files to the JsReport Playground I was unable to make it error, it produced an 86 page document (which is not huge I would think)
I have checked the Azure Webapp to make sure its not barfing on memory and its not, the VM is not huge but the memory graph shows its sits well under 10% usage always.
The following Dropbox link has the Template and Sample Data, although I doubt its of much use since the Playground renders it fine
https://www.dropbox.com/s/w7f59houwk2ao24/JsReport PDF Protocol Error.zip?dl=1
Below is our straight forward Docker file, from 2.5.0 it installs a config override + a few extra NPM modules and our helper Node module - the Puppeteer downgrade to 1.11.0 also shown
FROM jsreport/jsreport:2.5.0-full AS prod
COPY jsreport.config.json /jsreport/jsreport.config.json
WORKDIR /app
RUN npm i
request
request-promise
url
tough-cookie
@sendgrid/mail
webpack
round-to
puppeteer@1.11.0COPY node_modules/virtualmgr /app/node_modules/virtualmgr
and the jsreport.config.json which essentially overrides some timeouts (this is not a timeout issue though)
{
"httpPort": 5488,
"allowLocalFilesAccess": true,
"store": {
"provider": "fs"
},
"blobStorage": {
"provider": "fs"
},
"templatingEngines": {
"timeout": 600000
},
"chrome": {
"timeout": 600000
},
"extensions": {
"scripts": {
"timeout": 600000
},
"html-to-xlsx": {
"timeout": 600000
}
}
}I also tried using the Dockerfile from 2.4.0 as my "FROM" which built ok (and should have used Chromium 64 with latest NPM JsReport) but when I run it it errors with
2019-08-19T14:51:52.991144204Z 2019-08-19T14:51:52.915Z - info: Initializing jsreport@2.5.0 in production mode using configuration file: jsreport.config.json
2019-08-19T14:51:52.991177604Z 2019-08-19T14:51:52.924Z - info: Searching for available extensions in /app/
2019-08-19T14:51:52.991183504Z 2019-08-19T14:51:52.977Z - info: Extensions location cache not found, crawling directories
2019-08-19T14:51:57.726926059Z 2019-08-19T14:51:57.495Z - info: Found 31 extensions
2019-08-19T14:51:57.731570662Z 2019-08-19T14:51:57.686Z - error: Error occured during reporter init Error: options contain values that does not match the defined full root schema. schema validation errors: rootOptions.store.provider should be equal to one of the allowed values. allowed values: ["memory", "fs"]
2019-08-19T14:51:57.731588562Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)
2019-08-19T14:51:57.731594162Z Error: options contain values that does not match the defined full root schema. schema validation errors: rootOptions.store.provider should be equal to one of the allowed values. allowed values: ["memory", "fs"]
2019-08-19T14:51:57.731599162Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)this appears to be something to do with my Azure environment variable of
"name": "store_provider", "value": "mongodb",
which should be fine as this hasn't changed and surely mongodb is still supported ?
-
We use docker as well.
We cannot move past version 2.4.0.
Our entire setup works using 2.4.0, but the minute that we update to 2.5.0 we get these errors.
I am not sure how we can make a replicable demo to show you. It can't be replicated in the playground.
-
@stevef51 I tried your export uploaded to dropbox and it works for me on image 2.5.0-full. I even multiplied the input data and it renders 766 pages pdf without errors. Can you try to run just the official image
jsreport/jsreport:2.5.0
without any config. Upload there export you shared and run the template. Does it break for you?@AB-D It would help if you upload somewhere or email me jsreport export which is failing for you.
-
@jan_blaha
This is weird, so I changed our Azure Webapp to use "jsreport/jsreport:2.5.0-full" as you suggested and removed all custom configuration (so removed MongoDb storage etc) - it still errors with that basic 2000 record report. However running the same Docker image locally with no custom configuration (so should be exactly same as the Azure Webapp) and it runs just fine, tested up to 511 pages without an issue.Jan, Are you able to test on an Azure Webapp ?
-
@jan_blaha
Ok, its something to do with 2.5.0 and Azure Webapp - I just updated the Azure Webapp to use my hacked "2.5.0 with Chromium 64" image which is the Docker file from 2.4.0 which NPM fetches latest JsReport - and this works fine, this image however does not include the MongoDb extension (+ a bunch of other extensions) since it logs only 31 extensions found at startup whilst the "-full" images find 49 extensions
-
Yes, I confirm the behavior. It crashed on the azure web app but locally it works. We will test it with the docker image that we will ship in a few days with jsreport 2.6.0 and come back here.
-
I fixed the error "Protocol error (Page.printToPDF): Target closed." replacing 'chrome-pdf' with 'phantom-pdf'
-
Hi probably doesn't help you but I just had the same issue and downgraded to 2.4.0 to fix it. Keen to know when 2.6.0 is ready so I can test it.
-
@odirleiborgert yeah, I know that is kindof a work around but I find most reports render better with ChromePDF, although there are some instances where PhantomPDF does a better job due to rendering glitches in ChromePDF
-
Hi @jan_blaha do you have any update on this issue and version 2.6.0?
-
@bjrmatos and @jan_blaha is there any update on this issue and version 2.6.0?
-
@AB-D so far we have updated the chrome version in docker from Chrome 73 to Chrome 76, so that should solve the problem in the incoming jsreport 2.6.0, but we are going to do the release in one or two days.
-
jsreport 2.6.0 is now released with respective docker images. The newer chrome which is part of it should work better in azure web app.