Months after a test case was hard-deleted from a managed case repository, what do the executions and inbound references that still name it actually show, and why was the damage invisible on the day?
answer
- a write now, a read later
- cascade or dangle, pick one
- a title with nothing behind it
- smaller totals still render fine
- the auditor is the first reader
basics
~20 sOld executions either vanished with the case or survive naming an identifier that no longer resolves, so a run shows a bare number or a stale title. Nothing errors on the day: the removal succeeds and nobody is reading.
solid answer
~50 sOne of two things happened, and you find out which by opening an old run. If the tool cascaded, the rows are simply not there any more and the run's totals are smaller than the ones that were signed off. If it did not, the rows survive but their case reference resolves to nothing, so each renders as a bare identifier or a stored title snapshot with no steps and no expected result behind it. Inbound references — an automated run reporting against a case, a defect pointing at one — behave the same way: they either stop matching or match nothing. The damage is invisible on the day because removal is a *write* and every consequence is a *read*. The write succeeds, nobody is reading, and the first reader arrives months later during an audit or a repeat cycle.
go deeper
Know that removing a case does not automatically clean up what pointed at it, and that an old run can end up showing a number where a case name used to be.
Explain the two behaviours a repository can pick — cascade the removal to executions, or leave them orphaned — and describe what each does to a closed cycle's totals and readability.
Show the diagnosis: removal is a write and every consequence is a read, so you go and open an affected old run yourself rather than trusting the absence of an error.
Frame it as an integrity guarantee the organisation either offers or does not: whether a shipped release's evidence is immutable, who may weaken that, and what the estate can still prove afterwards.
## What survives a removal, and what does not A case record and the things that name it are stored separately. When the case record goes, the tool must choose what to do with the rest, and the two common choices produce very different wreckage: - **Cascading removal.** Executions recorded against the case are removed with it. Nothing dangles, because nothing is left to dangle — but a closed cycle now sums fewer rows than it did at sign-off, and no artefact says why. - **Non-cascading removal.** Execution rows survive with a reference that no longer resolves. Totals are preserved; readability is not. Both are defensible engineering choices, and both are indefensible surprises. Establish which one your repository does before anyone deletes anything in the live estate. ## What the surviving row renders as A dangling execution row is not an error page. Tools degrade rather than fail, and the degradation takes a handful of recognisable shapes: - A **bare identifier** where a case title should be — a number in a list of names. - A **stored title snapshot** captured when the execution was written, so the row reads normally but expands to nothing. - A row that is **absent from the case-oriented view but present in the run-oriented one**, because the two are built from different sides of the same relationship. - An **export that still carries the identifier**, so downstream consumers keep matching on a key that no longer exists upstream. The title snapshot is the most treacherous of these, because it looks healthy. A reader sees a plausible name against a pass and concludes the release was verified; there is no longer anything behind it that says what was verified. ## Why the day of the delete is quiet 1. **Removal is a write; every consequence is a read.** The write succeeds. Nothing in the tool is obliged to walk the graph and complain. 2. **Repositories rarely refuse a delete on the grounds of inbound references.** Enforcement would mean traversing executions, automation mappings and tracker links on every removal, and products generally do not. 3. **The person deleting is not the person reading.** The remover is tidying today's tree; the reader is auditing last year's release. 4. **Reports keep rendering.** A smaller total is still a valid-looking total. There is no marker distinguishing it from an honest one. 5. **Deletes arrive in bulk.** A folder cleanup removes many records in one action, so the blast radius is set before anyone inspects a single consequence. ## Who eventually finds out - The **auditor** reading a signed-off release, who asks what a passing row actually asserted and gets no answer. - The **engineer repeating an old cycle**, who cannot reconstruct what the previous run covered. - The **report consumer**, who notices a historical figure disagrees with the one printed at the time and has no way to reconcile them. By then the actor and the timestamp of the removal may themselves be beyond the trail's retention, so even *what happened* becomes a reconstruction. ## What to do when you inherit it 1. **Do not delete the leftover rows.** They are the last evidence that something was executed; removing them for tidiness destroys the residue. 2. **Capture what is still legible** — identifier, any stored title, run date, outcome, actor — before anything else ages out. 3. **Mark the affected releases as approximate** rather than restating the shrunken totals as fact. 4. **Fix the policy, not the symptom.** The rows are a consequence; the cause is that hard delete was available and used as a tidying tool. 5. **Move the estate to archive-by-default** so the next retirement is a state change instead of a removal. ## Preventing it The prevention is unglamorous and complete: **retire by archiving**, keep hard delete for records that were never executed or referenced, and restrict who can perform one. If a bulk removal really is required, do it while a restore window still covers you, and read an affected old run immediately afterwards rather than assuming silence means success. Silence is the failure mode, not the evidence of health.
- You inherit an estate where several past runs contain rows with no readable case behind them. What do you do first?Preserve, then diagnose. Do not delete the rows: they are what remains of the evidence. Capture the identifier, any stored title, the date and the outcome while the trail is still there, mark the affected releases' figures as approximate rather than restating them, and only then change the removal policy that produced them.
- Is preserving a removed case's title on the execution row good design or a trap?Both. It keeps a run readable, which is genuine value. The trap is that a title is not a specification: readers treat the snapshot as though it were the case, so a pass against a name nobody can expand looks like stronger evidence than it is. Rows in that state should be rendered as historical, not like ordinary ones.
saying these in an interview costs you the question
- Assumes the tool blocks a delete while references exist
- Deletes leftover rows to make old runs look tidy
- Treats a preserved title snapshot as the case itself
- Expects removal problems to surface immediately
- Restates shrunken historical totals as if authoritative