Thanks that should work for us.
Can we get the schema changes between 4.7 and 4.8 as well as 4.8 and 4.9 if there are any?

Our current setup is with Postgres db and AWS blob storage (saved for 30days). If the update to jsreport requires us to create a new schema in the database all references to the reports in our AWS are now lost.
And we run into two issues..

1. The client no longer has access to this report and will need to regenerate it. Which is problematic as we send out emails with links to these reports some times.
2. The report will now need be cleaned up manually due to Jsreport no longer knowing it exists.

Is there a way to migrate these references between schemas when we do this?

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)

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.