See https://discourse.phabricator-community.org/t/herald-rule-not-adding-auditors-to-commits-following-upgrade/3505/, where an install ran into an issue apparently caused by a broken project graph.

Once fixed, visiting one of these objects produces a misleading error message about policy issues. Although this is technically sort of accurate (the policy layer is failing into a closed state), it's not as clear as it could be.

When we filter an object in the policy layer for data integrity reasons (for example, some child object C which the mandatory parent P is missing for), it would be helpful to annotate the policy exception and propagate this to the handle layer and the policy explanation layer, so "Broken Object" is a separate state.

To reproduce:

• Create parent project P.
• Create subproject S.
• Mangle the parentPath on S in the database so it references a nonexistent lineage.
• Load the project page for S.

Actual behavior:

• Policy warning listing the object policy.

Desired behavior:

• Policy warning maybe listing the object policy, but more importantly saying "This object is broken and an ancestor didn't load, so this isn't truly a policy problem. The policy system is just denying access by default, but this is a symptom of a data integrity problem."