(Oban Pro 1.6.0-rc.4)
When I create a sub-workflow, it gets the parent workflow’s put_context
while losing the parent workflows add_cascade
additions to context
as well as the sub-workflow’s own put_context
Example of what I am experiencing (simplified):
def foo_workflow do
Workflow.new()
|> Workflow.put_context(%{foo: 1})
|> Workflow.add_cascade(:bar, &get_bar/1)
|> Workflow.add_graft(:baz, &baz_workflow/1)
end
def get_bar(%{}), do: 2
def baz_workflow(%{}) do
Workflow.new()
|> Workflow.put_context(%{banana: "yum"})
|> Workflow.add_cascade(:help, &help/1)
|> Workflow.apply_graft()
|> Oban.insert_all()
:ok
end
def help(%{banana: banana}) do
# this will not match because it has:
#
# %{foo: 1}
#
# but I am expecting to be able to match
# on `:banana` key.
#
# Sometimes `baz_workflow` is used on its own,
# and sometimes as a sub-workflow in `foo_workflow`.
end
1 Like
Thanks for the report! You’ve hit on some things that should be explained, warned about, or possibly fixed in workflows.
The context
is pulled from the current workflow, then the parent workflow if nothing was found; they aren’t merged. They certainly could be though. The top level cascade (:bar
) could probably be propagated down to the sub-workflow as well.
Looking into some fixes and improvements now.
2 Likes
Thanks.
My main issue is that the bar_workflow
is sometimes used on its own, and other times as a sub-workflow of foo_workflow
.
Right now it works fine on its own, but not when used as a sub-workflow.
Propagating parent cascades would solve this case, but it would be nice if put_context
calls in sub-workflows were merged into context as well.
(or if the sub-workflow’s own put_context
wasn’t ignored, that would also solve my case.)
or if I could pass other arguments into add_cascade
Workflow.add_cascade(workflow, :foo, &foo(&1, other_thing))
or
Workflow.add_cascade(workflow, :foo, &foo/1, context: %{foo: 1})
It wasn’t supposed to be. Just a bug in the query. It’s fixed for the next RC, slated in the next couple of days.
1 Like