ryanwinchester
apply_graft/2 doesn’t rewrite an add_many sub-workflow’s deps on an add step. Grafted jobs cancel with “upstream job was deleted”
Versions: oban_pro 1.7.12, oban 2.24.0, Elixir 1.20.3 / OTP 28, Postgres, Smart engine.
Also reproduced on oban_pro 1.7.8 + oban 2.23.0.
Summary
Inside a process/1 grafting callback (defined via add_graft/4), building a sub-workflow
that mixes add/4 and add_many/4 with deps: between them produces unresolvable
dependency references after apply_graft/2.
Specifically: when an add_many step depends on an add step, the add_many jobs are
inserted with meta.deps entries of the form [<pre-graft workflow id>, <step name>] —
but that workflow id belongs to the transient Workflow.new() built inside the grafter
and is never persisted (the add step’s job is re-homed under grafted_<id>). As soon
as the dependency completes, the add_many jobs are cancelled with:
** (Oban.Pro.WorkflowError) upstream job was deleted, workflow can't complete
The reverse direction works: an add step depending on an add_many sub-workflow gets
its deps correctly rewritten to [[<sub-workflow id>, "*"]].
Reproduction
defmodule Repro.NoopWorker do
use Oban.Pro.Worker, queue: :default, max_attempts: 1
@impl Oban.Pro.Worker
def process(_job), do: :ok
end
defmodule Repro.Graft do
alias Oban.Pro.Workflow
def new do
Workflow.new()
|> Workflow.add_graft(:rebalance, &__MODULE__.graft/1, queue: :default, max_attempts: 1)
end
def graft(_context) do
sells = Map.new(1..2, &{"sell_#{&1}", Repro.NoopWorker.new(%{"s" => &1})})
buys = Map.new(1..2, &{"buy_#{&1}", Repro.NoopWorker.new(%{"n" => &1})})
Workflow.new()
|> Workflow.add_many(:sells, sells) # also fails with add_many(:sells, %{})
|> Workflow.add(:fund, Repro.NoopWorker.new(%{"fund" => true}), deps: :sells)
|> Workflow.add_many(:buys, buys, deps: :fund) # <- these jobs cancel
|> Workflow.apply_graft()
|> Oban.insert_all()
:ok
end
end
Oban.insert_all(Repro.Graft.new())
Observed
Job meta after execution:
| step | state | meta.workflow_id |
meta.deps |
|---|---|---|---|
| sell_1/2 | completed | 01…748c (retained sub-workflow id) |
[] |
| fund | completed | grafted_01… |
[["01…748c", "*"]] |
| buy_1/2 | cancelled | 01…7073 (retained sub-workflow id) |
[["01…744c", "fund"]] |
01…744c is the id of the transient Workflow.new() built inside the grafter — no
persisted job carries it, so dependency resolution treats the upstream as deleted and
cancels the buys.
Expected
The buys’ deps should reference the fund job’s post-graft workflow id (grafted_…),
the same way the fund step’s dep on the sells sub-workflow was rewritten.
Notes
- Possibly related to the v1.7.5 fix “Preserve sub-workflow identity through
apply_graft/2” — the sub-workflow keeps its identity, but its outward dep
references aren’t remapped. - Workaround: build the graft exclusively with individual
Workflow.add/4calls;
all jobs then co-home undergrafted_<id>and deps resolve as plain name refs.
Trending in Questions
Other Trending Topics
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
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security










Showing Posts 1 to 1- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
sorentwo
Thanks for the report. That’s a twisty one!
It’s fixed on main for v1.8, but since you have a workaround we probably won’t backport it to v1.7.