A Microsoft Fabric pipeline runs ten activities, and one downstream Copy activity fails. The monitoring view shows the failed run, but the team needs the specific error message and the source row count the activity reached before it stopped, so they can decide whether the source file was malformed. Where should they look first to get this detail without re-running the pipeline?
- AThe Fabric capacity metrics app, which surfaces the compute units the pipeline consumed and shows the per-activity error text alongside the throttling events for that run.
- BThe Copy activity's output and error details on the failed run in the pipeline run-detail view, which records the error message and the rows read before the failure. Correct
- CThe Lakehouse table's Delta transaction log, which lists the commit that the Copy activity attempted and records the rejected rows together with the source error returned.
- DThe workspace recent-runs list, which shows each pipeline run's overall status and duration and links the failed activities to their full error output by default.
Why A is wrong: The capacity metrics app reports compute consumption and throttling, not per-activity error messages or rows-read counts, so it cannot answer whether the source file was malformed.
Why B is correct: Each activity's run detail captures its output payload including the error message and rows-read counters, so opening the failed Copy activity in the run-detail view gives the needed diagnostics without any rerun.
Why C is wrong: The Delta log records committed table versions, not a failed activity's source error or its partial read count, so a failure that never committed leaves nothing useful there.
Why D is wrong: The recent-runs list summarises run status and duration but does not itself display the per-activity error text and row counts; you must open the run detail to reach those, so it is not where the detail lives.