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
In scenarios where we have recently manually killed a job (via kill -TERM on the worker VM or similar), clicking on the job ID on the batch UI page to go to the particular job page instead results in 500 Internal Server Error.
Finding the server logs (see below) indicates that the problem is a record in the attempts database table with both start_time and end_time being NULL. Looking in the database shows that the record in question is the one for the next yet-to-be-started attempt, not the attempt that has just been killed (which in our observations has had end_time at least filled in).
This could be addressed by ensuring that at least one of these fields is always non-NULL, or more likely by making the attempts.sort(…) invocation more robust, e.g., via
What happened?
In scenarios where we have recently manually killed a job (via
kill -TERM
on the worker VM or similar), clicking on the job ID on the batch UI page to go to the particular job page instead results in500 Internal Server Error
.Finding the server logs (see below) indicates that the problem is a record in the
attempts
database table with bothstart_time
andend_time
being NULL. Looking in the database shows that the record in question is the one for the next yet-to-be-started attempt, not the attempt that has just been killed (which in our observations has hadend_time
at least filled in).This could be addressed by ensuring that at least one of these fields is always non-NULL, or more likely by making the
attempts.sort(…)
invocation more robust, e.g., via(where
MAXINT
is a suitable value to make these entries sort last)Version
0.2.133
Relevant log output
The text was updated successfully, but these errors were encountered: