orphan-cascade

The dangling reference and orphan cascade

Something was deleted or renamed, and the change did not reach every row, pointer, cached identifier or stored configuration that referenced it. The removal appeared to succeed. The failure arrives later, somewhere else, in whatever dereferences the orphan next.

The repair is where this archetype bites twice. A reference left behind by a rename must be remapped and a reference left behind by a delete must be pruned, and applying the wrong repair deletes live configuration.

Symptom

A removal or a rename was carried out and reported as done. Later, and usually in a different part of the product, something fails: a screen will not load, a report is missing rows, a job throws on a lookup, a saved view points at nothing. The reporter rarely connects the two, so the report describes the detonation and not the removal.

What Crumbtrail can see

Where the database adapter is installed, a session carries the exact rows that changed with their before and after values, pre state reads taken before a mutation, and the query activity that produced them. That is the strongest evidence available for this archetype, because it shows what the delete actually touched rather than what it was supposed to touch.

Named detector signals that speak to it include orphaned_reference, existing_children_reparented_to_new_row, db_delta_mismatch, db_unrequested_clear, acknowledged_write_never_landed, acknowledged_batch_rows_missing and request_target_row_mismatch. Alongside those, the session carries the request that carried the removal and, when both happened in one recording, the later request that detonated, plus the console error at the detonation site.

It does not carry rows in tables nothing touched during the recording. Crumbtrail records what the session's queries did, not the state of the database, so it cannot enumerate every dangling pointer that now exists. It also cannot tell a rename apart from a delete followed by an insert unless the queries themselves make that explicit. That second limit matters, because RENAMED versus DELETED is exactly the discrimination the repair depends on, and it is frequently not answerable from telemetry. When it is not, say so and settle it from the schema and the code.