I see. Would you please share a minimal playground demo replicating the issue?
https://playground.jsreport.net/

Handlebars doesn't have an eq helper, but you may easily add it.

I apologize for the delay. It looks like we will do the change and start calculating the reportTimeout after the worker starts processing. It will be the most likely part of the 4.11.0 (your license will work with that)

The reportTimeout is based on when the request arrived. This was designed a couple of years ago and still works the same with no complaints so far. However, I understand this doesn't play so well with async requests.

We will reconsider this and come back shortly.
Thank you for the ideas.

The 4.10.1 including pdf utils fixes has been released
https://github.com/jsreport/jsreport/releases/tag/4.10.1

Great, thank you. I can replicate the problem.
Chrome has again changed how it is structuring the output PDF. We will need to adapt some parts.
Expecting to release hotfix 4.10.1 with the fix tomorrow.
I apologize for the inconvenience.

Feel free to post the details here or create a new post.

I've tried the exact steps from here
https://jsreport.net/learn/ubuntu
In a fresh Azure VM with Ubuntu 22.04 and I see no issues.

Could you isolate what you have different?

You may experience a wrong footer alignment issue when updating to jsreport 4.10.0 in case you use the CSS code from our samples or the studio pdf utils quick action to add header/footer. You will notice this visually when the footer is at the top and not at the bottom.

The reason for this is not the jsreport itself but the Chromium 138 dependency update, which changed the CSS flexbox engine calculation. This caused the CSS used in our demos to position the footer to the bottom to stop working.

Fortunately, the fix is easy.
Find the template you merge as the header/footer and locate the following CSS

.main {
     ....
  height: 100%;
}

And change the 100% to 100vh

.main {
     ....
  height: 100vh;
}

Could you share an example when the index gets broken in 4.10.0?
I don't see this problem in our samples.