Hey Hopefully you can help us out we are trying to switch from using options.reports.async to using jsreport-Options-Reports-Async in the header. And when we run things locally without a DB connection all works well. Once we put it in our labs environment using "@jsreport/jsreport-postgres-store" we get the error bellow. We looked into the odata-to-sql and package but we are a bit stumped as to what would be causing this issue.

(because) cannot read properties of undefined (reading 'forEach')
TypeError: Cannot read properties of undefined (reading 'forEach')
    at module.exports (/app/node_modules/@jsreport/odata-to-sql/lib/query.js:54:28)
    at Object.query (/app/node_modules/@jsreport/odata-to-sql/lib/transformer.js:46:14)
    at Cursor.toArray (/app/node_modules/@jsreport/sql-store/lib/sqlProvider.js:22:29)
    at replay (/app/node_modules/@jsreport/jsreport-core/lib/main/store/collection.js:53:21)
    at /app/node_modules/@jsreport/jsreport-core/lib/main/store/collection.js:60:18
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.findOne (/app/node_modules/@jsreport/jsreport-core/lib/main/store/collection.js:93:17)
    at async findEntity (/app/node_modules/@jsreport/jsreport-core/lib/main/store/setupValidateShortid.js:63:26)
    at async validateShortid (/app/node_modules/@jsreport/jsreport-core/lib/main/store/setupValidateShortid.js:45:26)
    at async ListenerCollection.fire (/app/node_modules/@jsreport/jsreport-core/lib/shared/listenerCollection.js:157:21)

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.