So I'm here to ask you some clarification regarding this choice.
following the doc I achieved the wanted behaviour with async request, however I'm suprised that the "ping" request return a 500 error message rather than a 200 with "not ready yet" instead
because basicaly the /status page is to tell you if the report is ready or not.

I really personnaly think it would be better to have a successful answer with just the content telling you the situation rather than having that 500.

Also this could allow for better/easier error handling on client side if they do request a document that fail during rendering, as the error code could be used to point what went wrong instead.

What is your opinion on that matter? =)

I don't see we would return "not ready yet" somewhere. We also return 500 if the report cannot be found at all, not when the rendering is not finished
https://github.com/jsreport/jsreport-reports/blob/master/lib/reports.js#L88

Sorry if I wasn't clear enough. But yes this is what I was talking about.

The thing is that it does throw a big error message into jsreport server console (which is probably normal then) with all the path details.
but then I did had some time out error during those test (trying to do some heavy load run) and I couldn't catch nor see which report actually failled in the process, ans so the ping system could not stop from pinging despite the fact that the report generation had failled

Does this happen for you also if you run just single report without parallel execution?
Do you use default fs template store?
Could you post here whole or critical part of log.txt?

The url served to you should always include the existing report id, because the item is created before the response is sent to you. I don't see a place for mistake in the code so far.

Okay so I did try generate only one document and it worked, I even pushed to 5 at the time and it worked too, arround 10 and systematicaly I would get that error.

if by log file you mean the error.log, then this one stay empty after encountering such behaviour I'm affraid :( (did delete the file and restarted jsreport to make sure it would be accurate)
if you ask for the reporter.log then again, the error is not logged in it, it seems it show only on the console so far. Since it's a bit long (+1000 lines) could I send it to you by mail?

I do use the default template store also.

I'm starting wondering if this would be related to the fact that I didn't set a limit to the wkhtmltopdf workers and since I'm running (for now) test on a local machine with 'low' performance (compared to a proper dedicated server) could it be that the issue might be hardware related?

my machine spec are the following (if this can help you in the investigation):

Windows 7 Pro SP1 x64
4Gb RAM
AMD Phenom 9650 Quad-Core 2.30GHz

I'll try to find a time and look at this issue.

Could you please apply this patch to your installation and try it again? The fix would be then part of the next jsreport release.
https://github.com/jsreport/jsreport-reports/commit/c630630dd5bf6cc1806e88af22a76e6065f02096

I did apply the patch and it's working like a charm now (get only 200, 201 and sometime 304 codes)

(did the test with 200 reports requests in parallel)

A big thank you for your help and time!!