What silently consumes a single-use activation link before an automated case ever opens it?

## Resolving a link is a write, not a read The mental model that causes this failure is treating a link as something you can look at. A single-use link is not addressable state you read; the first successful request to it **is** the transaction. Anything that issues that request — your case, a helper, a reporting hook, a machine in the delivery path — has performed the activation, and everyone who arrives afterwards is legitimately refused. So the diagnosis is never "the product is wrong about single use". It is "something issued the request before the act step did", and the work is finding which of a small number of usual suspects it was. ## Where the extra request comes from | Source | Where it lives | The tell | | --- | --- | --- | | A reachability pre-check | The case's own helper, one line above the act step | Fails on the very first run of a new case | | A blanket retry around the consuming step | A shared runner helper nobody re-reads | Fails only when the first attempt was slow | | An artefact or report collector that visits captured links | Reporting hooks, teardown | Started with a reporting change, not a product change | | A scanner or preview generator between sender and capture point | Infrastructure the run does not own | Fails on every case, everywhere, from one day onward | | A speculative fetch by whatever renders the link | A browsing engine, a client that previews pasted links | Only when the link is rendered rather than requested directly | Two of those are yours, three are not, and telling them apart is most of the job. The first-run tell and the reporting-change tell are the fastest discriminators, because they say when the extra request started existing. ## Separating inspection from resolution The durable fix is a rule the whole suite follows: **inspecting a link and resolving it are different operations, and only the act step resolves.** Everything you would reasonably want to check before opening the link can be checked on the extracted text without touching the network at all: - that the address points at the expected route - that the expected parameter is present and non-empty - that it points at the deployment under test rather than a stale host baked into a template - that exactly one candidate link matched That covers essentially every reason a case reaches for a reachability check, at zero risk. Once the rule exists, "let me just confirm the link works first" stops being a reasonable-sounding suggestion in review. ## Retries are the subtle one The reachability check is an obvious bug once seen. The retry is not, because it is usually somewhere else entirely — a helper that retries any step raising a transport error, applied uniformly and sensibly to every other step in the suite. The failure mode is precise: the first request reaches the product, the product consumes the link and does the activation, and then the response is lost or the client's deadline expires. The step raises, the helper retries, the second request is refused because the link is genuinely spent, and the case reports "link already used". The real defect was a slow response; the reported defect is the one-shot rule. Every re-run reproduces it, which makes it look deterministic and product-shaped. Two repairs work. Exclude the consuming step from generic retries, so a transport failure there surfaces as itself. Or make the retry re-provision: on failure, go back and cause a new message to be issued, extract a new link, and start the act step over. The second is more work and is the right choice when the flow is genuinely flaky for reasons you cannot remove. ## Telling your own case apart from something upstream When the tells above do not settle it, run the experiment: extract the link, assert its shape, and **stop without issuing any request**. Then ask the product whether that link is consumed. - Still unused: nothing upstream is fetching it, and the extra request is inside your case. - Already consumed: something between the sender and your capture point resolved it, and no change inside the case will help. If the product records who consumed a link and when, that answers it outright — a consumption stamped before your run started is unambiguously not yours. That record is worth asking for before you need it. ## Fixes that stick Case-level fixes hold only until the next person adds a helper, so push at least one fix outward: 1. **Move the capture point ahead of any scanning or preview hop**, so the run reads the message before anything else can follow its links. 2. **Ask that resolving the link be safe to repeat for the same requester** — the second request from the same session or the same correlation returns the same result instead of a refusal. That removes the whole class of failure for every suite at once, 3. **Write the inspect-versus-resolve rule down** where the extraction helper lives, so the next reachability check gets caught in review rather than in a flaky pipeline three weeks later. The one repair that is never right is raising the waiting deadline. The link was not late; it was already spent.