adammokan
I’ve used the after_process/3 callback a number of times when implementing a Oban.Pro.Worker and it tends to work great for handling any cleanup or updating something in the database based on the job status.
I have a situation today where I’m implementing a Oban.Pro.Workers.Workflow with up to 3 dynamic child stages appended during execution and I realized I want to have a final callback that allows me to update a supporting record in the DB when the entire workflow completes. Reached for the after_process callback and instinctively added that to my first workflow stage, but (logically in hindsight) it fires right when that first stage completes rather than the entire workflow itself.
My primary question here is if I am missing something on how to handle this via a callback when using workflows? Or is the answer to append that final step I hoped to handle in the callback as a child of the workflow as its own job or is it recommended to attach that callback to the final stage of my workflow?
I think what makes this a bit confusing is that we do have a workflow-centric callback in the form of after_cancelled/4. So it seems like we should have some way to do the same for workflows that were not cancelled?
Appreciate any insight on this!
Update: I did just realize after_cancelled/4 is brand new as of last week. So maybe a similar approach for success cases is in the works 
Where Next?
Trending in Questions
Other Trending Topics
Latest Oban Threads
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Producing high quality Elixir screencasts since 2017.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sorentwo
You’re not missing anything—appending a final job as the last step or adding an
after_process/3callback to the final job in the workflow is the way to solve this. I’d suggest a final job over a callback because you’ll have all the niceties of a job (i.e. retries), and it’s more obvious if you look at the workflow as a whole.That callback is brand new (as noted in your update), and it was added to handle a situation that was impossible before. Prior to
after_cancelled/2, there wasn’t any way to react to downstream workflow jobs getting cancelled because they weren’t actually running.This use-case comes up frequently and a first-class approach for “batch callback” functionality in workflows is in the works