Less excited to announce the release of Oban v1.0.0-rc.2, but alas there was a bug in the V8 migration. Thanks to @benwilson512 for the bug report.
From the tiny CHANGELOG
flush.
Oban v1.0.0 is out along with ObanWeb v1.0.1. There aren’t any changes between rc.2 and 1.0, so nothing to report from the CHANGELOG this time 
This means that the API and migrations are stable and there won’t be any breaking changes (though there may be some deprecations). There is more to come! Some exciting features are already planned and under development.
@sorentwo Thanks again for this great library, just upgraded to 1.0 with no problems.
I have another question 
. I’m wondering if there is a recommended way to await the completion of a job or somehow be notified that a specific job is complete without resorting to polling. I saw the omen library by @LostKobrakai from a few month ago which has some interesting ideas, but was wondering if there’s any built-in features I should be considering?
I basically want to be able to enqueue a job and then wait for it to complete before moving on the the next step in a sequence of events. For instance keeping an http connection alive while a short running job is run on another service. I’ve thought of using telemetry to be notified, but I suppose it would need to be a general process that monitors all jobs instead of something like waiting for a specific job?
I think this is achievable using existing telemetry hooks! You could register a telemetry handler on job completion events, and in that handler do a Phoenix pubsub publish. Processes that want to wait for job completion subscribe to a topic based on the job id or arg. Alternatively, you can also just do a phoenix pubsub at the end of the job.
Thanks @benwilson512, I think that’s a pretty smart way to approach it.
I’ve started playing with that solution, but one issue I’m having is that the service that enqueue’s the job is not the same as the worker service, so none of my telemetry events are showing up on the enqueueing service.
I’ve tried some different configs to get the telemetry events without subscribing as a worker but haven’t figured anything out yet. Does anyone have any ideas on how a service can receive Oban telemetry events for a queue without subscribing as a worker?
To be clear, telemetry isn’t pubsub, rather you use telemetry events to trigger calls over phoenix pubsub. The worker service would attach a telemetry handler on boot to the Oban events. Your handler in the worker service would then perform a publish over phoenix pubsub. The thing to figure out is: how does your enqueing service subscribe to phoenix pubsub topics within your worker service? You’ll have to elaborate on how those services communicate.
I haven’t done this with Oban specifically (I used Sidekiq), but I think the approach could be viable here. If the enqueueing service has a known value (like a job ID or some manually generated token passed into the job), then it could subscribe to the PubSub topic like "job_completed:MY_ID". A subscribed process will receive a message when it goes over the PubSub, so you’d literally just be using receive with a timeout that you want. I do notice that the Oban Job struct has an id field.
I would probably approach this by having the job itself tell your system that it’s done processing (broadcast as the final step of the job). I say this because I’d want to avoid a mix of hooks defined across the system.
This advice is a slight tweak on Ben’s useful advice.
I actually agree that this should be probably handled as an actual part of the job’s function, instead of as a hook into Oban’s inner workings. Telemetry events are about providing insight into the working of your code as a system, if users are waiting on logical tasks to be completed that’s a business layer concern and should probably be handled at that level.
As suggested by @benwilson512 and @sb8244, this is definitely a place to use PubSub. You can’t rely on Telemetry because it is only single node.
An alternative to using Phoenix PubSub (if you don’t happen to be using it or you’d like an “Oban native” option) is to piggy back on the Postgres pubsub system that Oban uses. You can use the undocumented Oban.Notifier module to subscribe to messages in your worker process, like so:
defmodule MyApp.WorkerA do
use Oban.Worker
alias Oban.{Job, Notifier}
@impl Oban.Worker
def perform(args, _job) do
:ok = Notifier.listen(Notifier, [:signal])
{:ok, %Job{id: jid}} =
%{}
|> MyApp.WorkerB.new()
|> Oban.insert()
wait_for_complete(jid)
end
defp wait_for_complete(jid) do
# Notifications are decoded from JSON before they are pushed to your process
payload = %{"job_complete" => jid}
receive do
{:notification, "oban_signal", ^payload} ->
{:ok, :finished}
_ ->
# Wait in a loop, there may be other messages on the `oban_signal` channel
wait_for_complete(jid)
after
5_000 ->
{:error, :timeout}
end
end
end
In your other worker, WorkerB in this example, you’d explicitly publish a message to the oban_signal channel.
defmodule MyApp.WorkerB do
use Oban.Worker
@impl Oban.Worker
def perform(args, %Oban.Job{id: jid}) do
do_stuff_with_args(args)
notify_complete(jid)
:ok
end
# The mechanism for publishing messages is a little tricky. There used to be a `publish` function on
# `Oban.Notifier`, but it was removed around the time that beats were added.
defp notify(jid) do
# Channels are prefixed with the pg schema name, this allows isolation between mutltiple
# instances of Oban in the same database.
channel = "public.oban_signal"
# The payload must be valid JSON, you could encode it instead of writing by hand.
payload = ~s({"job_complete":#{jid}})
MyApp.Repo.query!("SELECT pg_notify($1, $2)", [channel, payload])
end
end
This has come up a few times in the past, enough that I’ve considered adding a function that abstracts all of the details here away and acts like async/await for Oban jobs. Something like Oban.insert_await/3, which would insert the job and block until it was complete.