This repository has been archived by the owner on Dec 13, 2023. It is now read-only.
[FEATURE]: Idempotent task execution within fork. #3861
Labels
type: feature
New feature
Comments
ivakoleva
added a commit
to ivakoleva/conductor
that referenced
this issue
Nov 27, 2023
Why: We need idempotent forked tasks, meaning all tasks get executed, but any failures are still detected upon join. Feature request Netflix#3861 What: Introduced the concept of Permissive tasks. A Permissive task is similar to a Simple task. The difference is, it permits the other tasks to continue - in case a Permissive task failed. Result is: 1. Forked Permissive tasks will let each other be evaluated, until all the forked tasks had terminated. Only then, the join task should fail. In case of Permissive optional tasks, the join will not fail. 2. Permissive sequential tasks will let subsequent tasks continue. While at the end, the workflow will fail in case a permissive task had failed. The workflow would not fail in case of Permissive optional task failure. Testing done: PermissiveTaskMapperTest added, TestDeciderOutcomes.testPermissive() added, WorkflowAndTaskConfigurationSpec "Test simple workflow which has a permissive task" and "Test simple workflow which has a permissive optional task added" that cover retry, ForkJoinSpec "Test a simple workflow with fork join permissive failure flow" added. In addition, performed e2e tests locally running a Conductor instance. Did build a docker image with the code changes made, started it locally, and started a SampleWorker to poll 3 tasks in parallel. Verified e2e scenarios of task_def_permissive, task_def_permissive_optional, task_def_simple.json, task_def_simple_optional.json, each joining on 6 forked tasks, then running simple task 7 after join.
This was referenced Nov 27, 2023
|
+1 |
1 similar comment
|
+1 |
|
@dimiturPavlovski in the case above, in the case of the JOIN is set as failed because one task failed. Should the retry of the fork execute all of the tasks or only the one that failed? |
|
In the current version of conductor when a task in a fork fails, only failed and cancelled tasks get retried. Which will make sense in the future request too. https://github.com/Netflix/conductor/blob/main/test-harness/src/test/groovy/com/netflix/conductor/test/integration/ForkJoinSpec.groovy#L254 |
6 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the Feature Request
Looking to have the capability to ensure idempotent parallel execution of tasks within a fork. It should be an alternative to the default fail-fast approach where, if a task fails within a fork, the other tasks get cancelled. The cancelled state causes problems on our side as it is a not deterministic state and the cancellation logic creates race conditions where other tasks within the same fork might get executed or might not.
Describe Preferred Solution
Describe Alternatives
We have a customer facing feature, that allows customers to define tasks as being optional or not. So for achieving idempotent execution of tasks within a fork we cannot leverage optional as it is reserved. Some tasks in the fork may be optional, or may not be optional. If not optional, we would like those to not interrupt the other tasks prior the join. Upon join, if any non-optional failed, we need to fail the join.
The text was updated successfully, but these errors were encountered: