we think that using a separate jsreportonline account is the best here, because it is more secure so you don't accidentally mess with that kind of duplicates.
In this case, something has deleted chrome.exe, not the jsreport binary. But chrome.exe was extracted from the jsreport binary.
As noted before, I would recommend configuring jsreport tempDirectory somewhere next to your application where you can guarantee nothing else is meddling with files there.
@mariocsantos Please create a new topic as this is quite old and share as much information as you can. The jsreport version, stack trace, do you have authentication enabled?, jsreport export if possible. The problem described here was about shared helpers from assets not being propagated to the child requests, but I believe it was fixed some time ago.
2020-04-16T13:07:01.275Z - error: unable to load planned schedules Error: Timeout during waiting for file system, try it again later.
This isn't a big problem, the file system, in your case s3, was too slow to respond so scheduling wasn't able to check planned schedules. It will just try the next time again.
Thank you guys.
I'm sorry for my late reply, but only today I had time to test correctly on my container. I only update to postgres-store 1.3.0 to 1.3.1, in my docker image, and now its working. Thanks.
You can disregard this issue. I had made a change to create a custom login screen that required modifications to authentication.js. I was just copying an older version of this file from a previous installation, but it looks like it was updated since then and the old version was not compatible. I apologize for the confusion!
