I’m learning about Oban, and I have been able to write some tests for a long-running task system I am writing that implements the Oban.Worker behavior.
If I start a Job and then call Oban.cancel_job with the job_id, while it is still executing, I can confirm that the state of the job was changed to “cancelled”. But I have two questions:
If I run Oban.check_queue after the job was canceled, the job id is still listed in the running jobs list. Could this be because my testing environment (Ecto Sandbox) doesn’t support PostgreSQL notifications? Or does a canceled job stay listed as running as long as it is still executing (even though it has been “cancelled”)?
Will my worker process receive any trappable signal from Oban, so that it can write logs, and do any necessary cleanup, or is it just brutally killed, or is the process left to run without any notice? Are there some examples somewhere I could look at for how to set up handlers if there is a way to trap a kill message from Oban? I’m not expert enough in OTP yet to understand where I should be setting up monitors or supervisors to handle this if it’s possible.
That is because your testing environment doesn’t support notifications. The cancel_job call will update the job, as you noticed, but it relies on a PubSub notification to tell the queue’s producer to kill the job’s task. That’s because you can call cancel_job on any node and have it kill the task wherever it is running in a multi-node cluster.
Oban cancels using standard OTP signals, so it may be possible to trap the signal in the task that wraps the job, but that isn’t something I’ve experimented with nor do I recommend it.
To write to logs or do some other cleanup you should create a handler and use the telemetry events that Oban emits.
