We have fixed the performance regression issue for v2-based templates where there are no handlebars tags present in the xlsx file. In other words, for templates that use just xlsxAdd, xlsxMerge... transformations.
The fix is currently in the master branch waiting for the next release, however you can already test it in the docker nightly build
docker run -p 5488:5488 jsreport/jsreport:nightly
I can imagine that the Chromium update included in v4.8.0 is causing the issue. That Chromium, for some reason, like insufficient resources, fails. While it was working fine with the older Chromium from v4.7.0.
Any chance you would be able to email me a working workspace/demo that I can use and try to replicate the issue?
Automated audit tools can be useful, but they often report false positives. In large, dependency-heavy projects like jsreport, these reports frequently flag issues that are not exploitable in practice and therefore don’t always provide meaningful, actionable security value.
For this reason, we won’t be releasing jsreport hotfixes on a more frequent schedule.
We take security seriously and run multiple audit scans as part of every release, working to satisfy their requirements. This process already requires significant time and effort, and we don’t plan to extend it beyond our current scope.
This is likely because you have updated the nodejs.
You have several options.
node --no-deprecation server.js or env NODE_NO_WARNINGS=1Unfortunately, there is 60s hard limit in jsreportonline
https://jsreport.net/learn/online-limits
If you want to render big reports with longer execution, you will need to switch to the onprem deployment.
Hi, the jsreport 4.12.0 includes the change.
Hi @Ish-Modi
It will be part of the next release 4.12.0 which should be live within two weeks.
Hi,
The fix is already in the master branch. I expect the release to happen within the next two weeks.
However, you can easily already apply the fix manually, it is just one line change
https://github.com/jsreport/jsreport/commit/b7c97212ca1bb7eba65475cdab7432e6fec4996f
That is very hard to tell. It could be a Chromium leaking bug causing it to become stuck.
Have you checked the memory consumption? Isn't Chromium leaking and growing the memory endlessly?
What if you try to loop and render those 6000 requests locally? Does it show the same behavior?
Check the /tmp and /dev/shm usage, isn't it getting full?
Perhaps setting config chrome.strategy=dedicated-process could help you.
This will ensure you have a fresh new instance of Chromium every time you render the request.
Thank you for reporting the problem.
I was able to isolate the issue. The latest Chromium interprets one of the configurations we use differently, which breaks the limited AWS Lambda runtime. We will try to reimplement the approach. Hopefully, it will be part of the next release. However, we still need to analyze the new approach, so no promises yet.
Here is the bug to track
https://github.com/jsreport/jsreport/issues/1271
Thank you for the template. We're gonna check if we can optimize processing a bigger XLSX template like this one
https://github.com/jsreport/jsreport/issues/1270
We will again update puppeteer/chromium in the next release. As always. Likely soon.
If you need to update just now, go ahead and update the puppeteer dependency.
You just need to list the latest puppeteer dependency in your package.json.
Or build your own Docker image with the updated Chromium. However, note that the latest Chromium with the fix is not yet in the public repository at the time of writing this post.
Unfortunately, this isn't supported yet.
I've added this feature to the backlog now
https://github.com/jsreport/jsreport/issues/1269
Hi,
Unfortunately, we don't provide a compiled version of jsreport in the latest release. There is a problem with the technology used for compilation. We will try to support the compiled versions again in the next release.
I've updated the release notes. I apologize for the confusion.
Jan
Unfortunately, it's not there. There was some controversy, but I am adding this now...
The dependencies will be updated with the next release as always.
https://github.com/jsreport/jsreport?tab=readme-ov-file#vulnerabilities
The release is scheduled for this week.
Yes, you can use a custom jsreport script where you can code what you need
https://jsreport.net/learn/scripts
https://jsreport.net/learn/pdf-utils#usage-in-script
const jsreport = require('jsreport-proxy')
async function afterRender (req, res) {
res.content = await jsreport.pdfUtils.merge(res.content, Buffer.from(req.data.externalPdf, 'base64'))
}
Full demo here
https://playground.jsreport.net/w/anon/2lCyXIBl
It works the way jsreport takes your html as is and puts it into the docx file source.
When you open the Word app, it interprets the HTML.
jsreport does not influence how it is interpreted.
Perhaps you can try the docx recipe and docxHtml helper, if you need to display just a simple html.
This would let you modify the page size and orientation in the word template.
https://jsreport.net/learn/docx#docxhtml