Previously, 3 protocol functions in overseer.store.jdbc used assert
to check the success of a row update (finish-job, fail-job,
heartbeat-job). However java.lang.AssertionError does not inherit from
Exception and was thus missed in the rescue codepath, causing app
crashes instead of going through error-logging paths. Furthermore if one
does not monitor or redirect stderr it can be extremely difficult to
detect the source of these "silent crashes".
This changes the named functions to use throw (ex-info ...) instead of
assert, which should be reserved for "impossible" system invariants,
and the failed-update behavior is now unit-tested.
Previously, 3 protocol functions in
overseer.store.jdbc
usedassert
to check the success of a row update (finish-job
,fail-job
,heartbeat-job
). Howeverjava.lang.AssertionError
does not inherit fromException
and was thus missed in the rescue codepath, causing app crashes instead of going through error-logging paths. Furthermore if one does not monitor or redirect stderr it can be extremely difficult to detect the source of these "silent crashes".This changes the named functions to use
throw (ex-info ...)
instead ofassert
, which should be reserved for "impossible" system invariants, and the failed-update behavior is now unit-tested.