You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're currently experiencing problems with failing batch job due to EJR availability. Each batch job does a health check request to the EJR, which now fails often. In the majority of batch jobs however, the EJR is actually not necessary, so this failing health check is an unnecessary cause of failure.
I'm now working on a quickfix to turn off the health check from batch job context.
Note that in other contexts (web app, job tracker) this health check is still useful to fail fast on misconfiguration, so I'll keep it on by default
Next step: fully eliminate the dependency on EJR from batch jobs (not only to improve stability, but also security).
The original "handle a user's own, but unsigned batch job result URL" problem could for example be solved before submitting the batch job
We're currently experiencing problems with failing batch job due to EJR availability. Each batch job does a health check request to the EJR, which now fails often. In the majority of batch jobs however, the EJR is actually not necessary, so this failing health check is an unnecessary cause of failure.
As far as we identified, the EJR dependency from within batch jobs is to handle a user's own, but unsigned batch job result URL: ba1135a#diff-aaeea51041d5a176c49b2dc6069775385a54ce83e97193ea95f87e3aea3c08df for #792
The text was updated successfully, but these errors were encountered: