A test case in a case repository stores a link to an item in an external issue tracker. Which identifier should that link store, and what happens to it when the item is renamed, moved to another project, or deleted?

A link from a test case to a tracker item is a foreign key across a boundary you do not control. Everything hard about keeping it correct follows from that: the other side can change the thing you pointed at, at any time, without telling you, and the only leverage you have is the identifier you chose to store. ## Two identities, only one of them stable Trackers expose an item under at least two names: - an **internal identifier**, minted when the item is created, opaque, never re-used, and not shown to users in most workflows; - a **human-readable key** — the short string people paste into chat and commit messages — and a **title**, both of which are display surfaces and both of which are editable. A **rename** changes the title. A **move** to another project usually rewrites the human-readable key, because the key encodes the project it belongs to. Neither event touches the internal identifier. So the choice of what to store decides, in advance, how many ordinary tracker operations look to you like a broken link: | Event on the tracker side | Link stored by internal id | Link stored by key or URL | |---|---|---| | Title edited | intact | intact | | Item moved to another project | intact | resolves to nothing | | Item deleted | unresolvable | unresolvable | | Integration account loses visibility | looks unresolvable | looks unresolvable | The last row is the one that catches people out: an authorization failure and a deletion produce the same not-found answer from most trackers, deliberately, so that a caller cannot probe for the existence of items it is not allowed to see. ## Store the identifier, cache the label The shape most case repositories converge on is: 1. **Resolve by the internal identifier.** It is the only value in the link that is a promise. 2. **Cache the key and title alongside it**, refreshed on every successful read, purely so a list of links is readable without a round trip per row. 3. **Never treat the cache as identity.** If the cached key and the freshly read key disagree, the fresh one wins and the cache is updated; that disagreement is the normal signature of a move, not an error to raise. That split also buys a cheap staleness signal. If the cached label for a link has not been refreshed in a long time, the link has not been resolved successfully in a long time, which is worth surfacing before somebody builds an argument on it. ## What a delete should do to a stored link Deletion is the only event that genuinely destroys the target, and it is the one where a product's behaviour is a real design decision rather than a mechanical consequence: - **Do not cascade the delete into your own store.** That a test case once verified a requirement is a historical fact; erasing the link erases the evidence that the coverage existed, and quietly improves every backward-looking number. - **Mark the link unresolvable and keep it visible**, with the last known key and title, so a human can decide whether the item was deleted, merged into another, or simply moved out of the integration account's view. - **Do not decide on a single failure.** One not-found may be a transient outage, an expired credential, or a permission change. Requiring the same failure on several separate attempts, spread over time, keeps a five-minute credential problem from marking a whole project's links dead. - **Make the state reversible.** If the item reappears — restored from a backup, or visibility restored — the next successful resolution should clear the mark with no human involved. ## The failure this prevents The characteristic incident is not dramatic. Somebody reorganizes the tracker over a weekend, moving a few hundred items into a new project. A repository that stored keys sees a few hundred links stop resolving on Monday, prunes them on the assumption that the items are gone, and its coverage figures drop without anyone having deleted a test case or a requirement. Nothing errored. The numbers simply became wrong, and because the links were pruned there is nothing left to reconstruct them from. A repository that stored internal identifiers sees the same reorganization as a batch of changed display labels, refreshes its cache, and reports on Monday exactly what it reported on Friday.