Pattern for Flows that contain Child Jobs with multiple Parent Jobs #2416
Replies: 3 comments 2 replies
-
After some initial testing, the method above seems to work -- For anybody looking for a similar solution, here is some code that may help :
a helper function to create copies of a job :
example usage :
A couple considerations about this implementation that may be relevant if you choose to use it : All copy cat jobs will immediately be added to the active state, regardless where their base job lives in the flow tree. So, if the base job relies on other long running processes before beginning execution, the copy cat could be running in the background for a while. I accounted for this by setting the global concurrency on the copy cat worker relatively high just to make sure it will be active whenever it's base worker is doing it's work (not waiting on other copy cats listening to other queues that could be delayed to clear the copy queue first). Also -- I set the worker configs on the queues that are being "copied" to remove completed / failed jobs based on time, not number. If you ever run into a scenario where your queues are turning over jobs faster than the interval at which the copy_cat is checking, it's possible for the copy job to have been deleted before the copy_cat can get back around to checking again. Pretty unlikely scenario, but just thought I'd mention it |
Beta Was this translation helpful? Give feedback.
-
@hhopkins95 You probably have |
Beta Was this translation helpful? Give feedback.
-
It would be really nice to have multiple parents work natively in flows without the need for a workaround like that. |
Beta Was this translation helpful? Give feedback.
-
Hello --
Is there a recommended pattern to accomplish flows in which multiple jobs need to await the same child job?
For example, something similar to :
where the completion of "Job A" should trigger execution of jobs B, C, and E?
I have tried defining the flow with this approach :
though, the child job will only trigger the parent who lists it as a child last -- (Job A will only trigger Job E, in the example above -- not B or C).
I'm considering creating a "CopyCat" queue like this :
and a Copycat processor :
Where the jobId for the "base" (Job A in this example) job will be passed as data to the CopyCat job(s) (JobA copy 1, JobA copy2).
The copycat worker will just read it's "base" job on some interval and copy over the statuses / results when the job completes.
This way every job will only have a single parent.
Is this a good solution, or are there cleaner ways to handle these types of flows?
I'm not sure if I'm overlooking anything that could be an issue with this implementation.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions