Thanks, upgrading to 4.8.0 fixes that issue.
However, now we are seeing an issue where if we set our workers to 1 it doesn't queue up after the first request everything just runs. Where before we used the header it would queue up but not respond with the location id until a worker was available.
We are currently on 4.7.0 we will try upgrading to 4.8.0 and see if that fixes the issue and let you know.
No Authentication enabled.
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)
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.