Closed andrewberls closed 9 years ago
:+1: but I think santization should be a sentry-handler concern, not an overseer concern
Wait sorry I rescind :+1: , I think we want the option that aborted jobs can actually hit Sentry
THe question is "what does an abort mean" and how/where/whether it should be surfaced
It's an open question I suppose. I think a decent compromise might be, log an abort warning with timbre but don't send to Sentry, as in practice for us aborts are a result of malformed/incomplete data and not an actionable item we can go fix. How do you imagine that option being specified?
:+1: nice
When a job is aborted from user code with
overseer/abort
, it's intended to signal that the job has failed and all of its dependents should be cancelled. However, internally this uses exceptions thrown with a special ex-info tag that Overseer catches and examines. Previously, all job exceptions were caught in the job exception handler, which indiscriminately shipped them off to the default exception handler, i.e. Sentry. Now, flow-control aborted exceptions are logged to Papertrail but no longer sent to Sentry.Misc refactorings are included - a per-commit review basis may be clearer
Followup work includes refactoring our definition of
fail
, which does not actually make much sense in practice.