Diagnostics Provider Input Lanes And Failure Isolation

Purpose

Diagnostics provider input lanes let validation providers declare the scene, prefab, catalog, UI, or input-profile data they need while keeping provider failures isolated from the rest of the run.

Steps

1. Choose the minimal input lane for the provider.
2. Declare source dependencies and report ownership.
3. Use lane signatures to skip unchanged work when safe.
4. Return completed, failed, or skipped run state explicitly.
5. Let later providers continue when one provider fails.

Expected Outputs

A diagnostics run should produce deterministic reports, clear provider status, and source dependencies for every issue. Provider failures should be visible but should not hide unrelated validation output.

Common Mistakes

Common mistakes include subscribing to broad lanes unnecessarily, panicking instead of returning provider failure, omitting source dependencies, or making a report-only provider look like it owns the primary asset.

Recovery Paths

If a provider fails, inspect its lane inputs and provider status first. If later reports are missing, verify failure isolation and catch_unwind behavior. If stale diagnostics persist, check lane signatures.

Related Pages

• Validation Provider Registry And Strict Preflight
• Shared Validation Report Schema
• Validation And Bake