A coordinator loses network connectivity to Worker Agent 2 mid-task. Worker Agents 1 and 3 continue running. When connectivity is restored 8 minutes later, the coordinator discovers Worker 2 completed its task during the outage and wrote results to its designated artifact store. What is the correct coordinator recovery action?

This scenario tests whether you understand that durable artifact stores decouple worker completion from coordinator observation. Worker 2 completed correctly and wrote its results to its designated artifact store — the work is done. The coordinator's connectivity loss was an observation failure, not a worker failure. The correct recovery (option B) is to read from the artifact store, validate the artifact (check schema completeness, integrity hash if available, and that the expected output fields are present), and treat the result as equivalent to a normally signaled completion.

Option A (re-running Worker 2) wastes compute, introduces latency, and may produce a different result if the worker is non-deterministic. More importantly, it incorrectly treats a coordinator observation failure as a worker failure. The diagnostic question should be 'did the worker produce a valid artifact?' not 'did the coordinator receive the signal?'

Option C (discarding Worker 2's results) is unjustified without evidence of corruption. The coordinator's connectivity gap does not introduce corruption into the artifact — Worker 2's process ran independently of the coordinator's connection. Discarding valid work because the coordinator lost network access is an overreaction that reduces pipeline output quality.

Option D (restarting the full pipeline) is the most wasteful option. Workers 1 and 3 ran without issues, and Worker 2 completed successfully. Restarting discards all three agents' completed work and introduces additional latency and cost with no benefit. Full restarts should be reserved for situations where the pipeline state itself is corrupted, not for coordinator connectivity events.