Chrome has real limits with very long tables — we can't remove them entirely, but we can push them out quite a bit.

It turns out one of the things Chrome hits first is accessibility tagging. Tagging a table with tens of thousands of cells blows up both the file size and Chrome's printing itself. This can be turned off, and I've pushed a tagged option to master; it will be in the next release.

You can already test it without upgrading — just add the following to the template

<script>     
    window.JSREPORT_CHROME_PDF_OPTIONS = {
        tagged: false
    }
</script>

In our tests this took the same report from failing at ~1100 pages to rendering ~1300 pages, with the output roughly 30x smaller. Please try this first, it may be all you need.

On your summary/cross-tab reports: those shouldn't be affected by this limit at all. Chrome's problem is the number of pages, not the number of input rows — a report consuming 200k rows and printing 2 pages renders in well under a second here. If one of those crashes, it's a different issue and worth a separate thread with the error.

One more thing to check: numberOfWorkers: 6 on 2 cores and 8GB is quite high. Each worker can hold its own Chrome plus your dataset, so that alone could explain the container crash. I'd try 2.

If you still need chunking for the really long ones, it doesn't have to break your totals — the trick is to compute aggregates once over the full dataset before rendering, split on group boundaries rather than row counts, and pass the precomputed subtotals and grand total into every chunk. Happy to go through it on a minimal demo if you can prepare one.

Thanks for checking.

I've pushed another fix, which should be released by the end of the week.

Thank you for your patience.

Thank you, that looks legit.
We will review it more deeply and update this in the next release.

Just to summary the observations we've sent through the emails...

The flag --disable-gpu causes chromium crash in case of the latest full image jsreport/jsreport:4.14.2-full
The default image, which is based on alpine, now doesn't need extra flags.

The fix should be part of the latest release.

The script adding an attachment should look like this

const jsreport = require('jsreport-proxy')
async function afterRender(req, res) {
  res.content = await jsreport.pdfUtils.addAttachment(res.content, Buffer.from('hello'), 
    name: 'my attachment'
  }, {
    pdfAccessibility: {
      enabled: true
    }
  })     
  res.content = await jsreport.pdfUtils.postprocess(res.content, {
    pdfAccessibility: {
      pdfUA: true,
      enabled: true
    }
  }) 
}

Please share the minimal workspace that replicates the issue.
You can confidentially email it to me jan.blaha@jsreport.net

Thank you for the topic. I will check it out and come back here.

Thank you, I can reproduce it now.
We will fix it in the upcoming release.

Are you able to email me your workspace export to jan.blaha@jsreport.net?
Or please try to isolate the problem by removing your folders to find out which entity is the cause.

It works for me in latest as well as in the 4.10.1.

Please share details when it happens.