Closed unforced closed 9 years ago
I'm not sure why we need this on top of our existing application exception harness for setting the same information in report instances? In theory we can already do
(defn my-job [job]
...
(throw ex-info {:report.instance/status :user/empty-cohort})
which will set the report instance status (which we can respond to appropriately) and generically mark the job as failed. Do we really need the additional layer?
If you look at the reports stats email, we already have some instances that have multiple different jobs failing, because of how the dependencies work out. In the future, we're going to want jobs to be more atomic, so that we can have certain parts of a report failing, but still allow the overall report to be displayed to a user. For that to work, we need to have the failure information on jobs themselves, rather than instances, otherwise the instance would have to store multiple failure types, and failure messages.
I see. I guess that makes sense, let me review with that in mind
Updated
:+1: nice, this is looking good
Add in
failure
andfailure-message
to overseer jobs This way, when jobs fail, we can mention a specific keyword, such as:system-fail/unknown
or:user-fail/empty-cohort
so that we can deal with the failures easier in other parts of the code, and start making it easier to figure out what is failing, for both us, and for the end users