Looks like this issue is resolved in v4.6.

We seem to be running into an issue and was wondering if its something you have seen before. we have some fairly large reports we are talking 1000+ pages that have a TOC (render twice approach). But these larger reports started timing out. we increased the time out and the one report took 1.5 hours to finish and when we removed the TOC it took 6 min.

We are using v4.4.0 at the moment, and think this started happening when we upgraded from v2.11. Appreciate any insight you might have on this. Maybe we need to update how we are handling the TOC.

This seems to be an issue with chromium v126:
https://github.com/puppeteer/puppeteer/issues/12601

OK thanks we will change that and see if it helps.

We are seeing the same issue in v4.5 when we tested this out v4.4 seems to work correctly.

We are getting the following error in our prod env after upgrading to jsreport 4.4.

Failed to clean up old reports Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. code=EREQUEST, originalError=Error: Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction., name=RequestError, number=1205, lineNumber=1, state=45, class=13, serverName=***, procName=, precedingErrors=, stack=RequestError: Transaction (Process ID 2) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

We have multiple instances of jsreport running on ubuntu in docker containers, we use mssql as our store and blobStorage is aws s3 buckets.

Error started 30days after we upgraded to 4.4 i'm assuming cause our cleaning threshold is 30d
Clean up configuration:
"cleanInterval": "3h",
"cleanThreshold": "30d",
"cleanParallelLimit": 10

Also we don't see the error in our labs env but there are a lot less reports generated there than in our prod env.

Any idea why we might be getting this when the reports cleanup happens? Could lowering the ParallelLimit help?

Thanks for taking a look we are working on switching over to div's instead of tables that seems to fix the issue.

I'm using some clickable links in my report to take the user to different parts of the PDF however after upgrading to 4.4 (from 2.11). Our links no longer seem to take you to where they should.
My current theory is if you use page break avoid the link doesn't seem to take in the extra space and brings you to where it would be if there was no page break.

I was able to reproduce the issue here:
https://playground.jsreport.net/w/joshplaetzler/TcjfssFB

Any idea on how we could get around this?

FYI: Tested this with just using divs instead of tables and didn't see the same issue so maybe that is the problem though we need to use tables throughout our reports and would like to avoid them getting split between pages when its not necessary.

Wanted to give an update. We found the issue the client was sending the request with Content-Type=application/octet-stream and this causes that error to be thrown.

Logged in the server logs.
We are on version 4.4.0
Template store we use mssql, blob storage we use S3 bucket.
We are seeing this with non async call only, but not always, and we do use async as well.
We are setup using docker but not using docker workers extension.

Here is a snippet of what we are doing we have our own endpoints configured and we have been editing the req and forwarding it on for jsreport to handle. We saw this once we upgraded to 4.4 which was just this week. We have tried but have not seen the error or been able to recreate it out side of our production env. If I succeed in doing so eventually I will edit that error to throw more info.

logger.info(`Retrieved Short ID ${shortid}`); // this logs with a valid shortId

req.url = "/api/report";
req.method = "post";
req.body = {
  template: { shortid: "shortid" },
  data: {
... // data the template will use
  },
  options: {
    reports: { async: false },
    "reportName": name
  }
};
req.app.handle(req, res, next);