In a workflow orchestrator, when one upstream branch of a fan-in task fails, what decides whether it runs?

## Fan-out, fan-in, and the join question Fan-out is one task with several children; fan-in is one task with several parents. Fan-in is where mental models break, because an edge only says "after", and after says nothing about *after what outcome*. That gap is filled by the downstream task's **trigger policy** (orchestrators name it differently, but the concept is universal): a rule over the terminal states of its upstreams that decides whether this task becomes eligible to run. ## The terminal states involved A task run ends in one of a few states — typically **succeeded**, **failed**, **skipped** (deliberately not applicable this run), and a derived **upstream-failed / blocked** state meaning "this task never ran because its dependencies did not satisfy its policy". That last state matters: a join with one failed parent is not itself failed. Nothing in it broke. Treating it as a failure produces noisy alerting that points at the wrong task. ## The policy menu Broadly, orchestrators offer some subset of: - **All succeeded** — the default. Every upstream must have finished successfully. - **All finished** — every upstream reached *any* terminal state; run regardless of outcome. - **None failed** — succeeded or skipped are both acceptable, but a failure blocks. This is the join-after-a-branch policy. - **At least one failed** — the alerting or compensation path. - **At least one succeeded** — best-effort merge over whatever completed. The names differ by tool; the semantics above are what you are actually being asked about. ## Choosing by what the task does The rule of thumb is: **match the policy to the blast radius of running with incomplete inputs.** - A task that writes a dataset consumers read — a merge, a load, a mart build — keeps the strict *all succeeded* policy. Publishing two of three regions as though it were the whole world is worse than publishing nothing, because downstream consumers cannot tell the difference and the number ends up in a report. - A task that releases a resource — deleting a scratch prefix, tearing down a cluster, dropping a lock, closing a ticket — needs *all finished*, or a failure upstream leaks the resource on exactly the days you can least afford it. - A notification summarising the run also wants *all finished*, otherwise the notification you most need is the one that never fires. - An escalation or compensation step wants *at least one failed*. - A join sitting after a conditional branch wants *none failed*, because one side of the branch is skipped by design on every run. ## The classic defect Someone sets a merge task to all-finished because "the run kept getting stuck". Now a failed regional extract no longer blocks anything: the merge runs over the partitions that exist, publishes a smaller table, and — depending on how run state is derived — the pipeline may even show green because the last task succeeded. Revenue is under-reported for a day and nobody is paged. If partial output is genuinely acceptable, make it **explicit** rather than silent: - record which inputs were present in a run-level metadata row or a column on the output; - publish to a location marked incomplete, or set a flag consumers check; - fire a distinct warning notification, not the normal success one; - and still fail the run's overall state so freshness and completeness monitoring sees it. Silence is the failure mode, not partiality. ## Best-effort fan-in done properly Some pipelines really are best-effort — scraping fifty sources where three are always down. Then *at least one succeeded* is right, but pair it with a floor: the merge itself asserts that, say, at least forty-five of fifty inputs landed and fails if not. That converts "how many is too few?" from an invisible property of the graph into an assertion in code that you can tune and test. ## What happens on the rerun When the failed branch is fixed, you rerun that task and everything downstream of it. This is where a clean graph pays off: because edges define the downstream closure, "clear this task and its descendants" is a well-defined operation. It is also why the join should not have quietly produced output — if it did, the rerun has to overwrite rather than fill a gap, and any consumer that already read the partial version has been served bad data. ## Fan-in also shapes timing A join with many parents starts only when the slowest parent lands, so its completion is governed by the worst branch, not the average. A retry deep in one branch pushes the whole join out. When one slow source keeps delaying every consumer, intermediate joins per group — so fast sources publish without waiting for the laggard — are usually a better answer than relaxing the policy. ## Interview framing State the default, name the alternative policies by their semantics, and — most importantly — say *which kinds of task get which*. Candidates who list policies without connecting them to cleanup versus publishing have memorised a table; candidates who say "the merge stays strict, the teardown goes all-finished, and partial output must be explicit" have run pipelines.