Fabric says a child pipeline failed to start, but a run exists

A parent pipeline reports job failed to start or a request timeout. The child run appears in Monitoring Hub anyway. A Fabric practitioner report describes this split state. The parent’s error and the child’s existence are two observations; neither proves the child completed its intended work.

Reconcile both sides of the invocation

Record the parent run ID, Invoke Pipeline activity ID, child run ID, start times and status transitions. Use Fabric Monitoring Hub to inspect the child’s activities and outputs. Confirm whether downstream writes, notifications or external calls occurred, even if the child still shows NotStarted or another ambiguous status.

Make the retry boundary explicit

Microsoft’s activity retry guidance supports retries for transient failures, but a timeout at the invocation boundary can leave uncertainty about side effects. Give the logical job a stable business key and make writes idempotent or deduplicated. Do not rerun the whole parent until the first child’s outcome is understood.

Escalate with a minimal timeline

If run states disagree after reconciliation, preserve the two run IDs, timestamps, region, capacity and error payload for Microsoft Support. A single controlled reproduction is more useful than many overlapping retries, which make the lineage harder to reconstruct.

Adovo’s view

Orchestration reliability is the ability to answer whether the work happened. A red parent status is not enough when a child may have written data. Design the retry around the business operation, not the button.