In Azure Data Factory, why can a pipeline report Succeeded after its Copy activity failed?

## Dependency conditions are the control flow ADF has no separate error-handling block. Ordering and error handling are the same mechanism: every activity's `dependsOn` array names prior activities and a condition on each. - `Succeeded` — run only if the predecessor succeeded (the default green arrow). - `Failed` — run only if the predecessor failed. - `Skipped` — run only if the predecessor was skipped, which happens when *its* condition was not met. - `Completed` — run regardless of outcome. Multiple entries on one activity are ANDed: every listed predecessor must satisfy its condition. Combined with the fact that an unmet condition makes an activity *skipped* rather than failed, this gives ADF a small algebra that surprises people. ## How the run status is computed The pipeline run's status comes from how the graph terminated — specifically from the final activities on the paths that actually executed. Take the common try/catch shape: ```text CopyOrders --(Succeeded)--> TransformOrders CopyOrders --(Failed)-----> LogError (Web activity) ``` If `CopyOrders` fails, `TransformOrders` is skipped, `LogError` runs and succeeds — and the run terminates with its executed leaf in a succeeded state. ADF reports **Succeeded**. The activity-level view still shows the Copy in red, but the run row in Monitor is green, the failure alert never fires, and a parent pipeline that invoked this one with `waitOnCompletion: true` continues down its own success path. This is the single most surprising behaviour in ADF error handling, and it is where the interview question comes from: a team "has alerting on pipeline failure" and still misses outages, because their error handler is doing its job too well. ## Making failure visible again: the Fail activity The supported fix is the **Fail** activity. Put it at the end of the failure path, after whatever logging or cleanup you want, and the run terminates Failed with your own message and error code: ```json { "name": "FailRun", "type": "Fail", "dependsOn": [{ "activity": "LogError", "dependencyConditions": ["Succeeded"] }], "typeProperties": { "message": "@concat('Copy failed: ', activity('CopyOrders').Error.message)", "errorCode": "COPY_ORDERS_FAILED" } } ``` Note `@activity('CopyOrders').Error.message`, which is how a downstream activity reads the upstream error text — useful for the log payload as well as for the failure message. The result is the best of both: the error is recorded somewhere queryable *and* the run is red, so alerting and parent pipelines behave. The alternative shapes are worth knowing by name. A "do-if-else" arrangement routes both outcomes and deliberately lets the run end green because the error is a business outcome, not an incident. A cleanup activity depending on `Completed` runs either way and is the ADF equivalent of a finally block. ## Skipped is not failed The second half of the surprise is `Skipped`. When `CopyOrders` fails, `TransformOrders` is *skipped*, and anything depending on `TransformOrders` with a `Succeeded` condition is skipped in turn, cascading quietly to the end of the branch. Skipped activities are not errors, which is why a partially executed pipeline can end green even without an explicit handler if the failing branch had no downstream leaf in a failed state. Reading a run's activity list and understanding which activities were skipped versus failed is a core Monitor skill. ## Repairing a run ADF's Monitor blade offers a rerun from a chosen point — commonly "rerun from the failed activity". This creates a new run that reuses the original run's parameter values and resumes at that activity, so the successful upstream work is not repeated. That matters when the upstream step was a two-hour copy and the failure was in a five-second stored procedure. Two caveats. First, rerun is only safe if the activities downstream of the restart point are idempotent — a rerun that re-appends the same rows creates duplicates. Second, reusing the original parameters is what you want for a date-parameterised load and is exactly *not* what you want if the parameters themselves were the bug; in that case start a fresh run with corrected values. For tumbling-window-driven pipelines there is a second layer: the window itself can be rerun from the trigger runs view, which reissues the whole pipeline with the same window boundaries. ## Interview signals Strong answers state that status is derived from terminal activity states, demonstrate the Fail activity, distinguish skipped from failed, and connect all of it to alerting — the real cost of the behaviour is not the green row but the page that never went out.