A tunnel to a browser provider outlived the job that started it — what does that cost the next run?

## How a tunnel outlives its job A tunnel is something that keeps running until something stops it. In a pipeline that something is a teardown step, and teardown is the part of a job that the unhappy paths skip: - The job was **cancelled** — a superseded push, somebody pressing stop — and the step that closes the path was never reached. - The **runner died**: out of memory, evicted, the machine reclaimed. Nothing local survived to clean up. - A step **failed before cleanup**, in a pipeline where teardown is written as the last step of the happy path rather than registered to run on any exit. - The teardown ran and **did not finish**, which is not the same as not running and is easy to mistake for success. Leftovers are not exotic. They are what a normal pipeline produces on its normal bad days. ## Why the damage depends on the name This is the part that is usually overstated in both directions, and the true statement is conditional. If tunnel names are **unique per job**, a leftover is a standing route that nothing will ever ask for. No later job names it, so none can be routed down it. It is still worth finding and stopping — it is reach into your network no live job accounts for, and it keeps consuming whatever it consumes — but it is not a correctness problem, and calling it one weakens the argument for the cases that are. If the name is **reusable** — one shared name, a name derived from the branch alone, anything a later run can produce again — the picture changes. The next job asking for that name can attach to a route the previous run built, pointing wherever the dead job's side pointed: a branch staging host since redeployed with different data, torn down, or rebuilt for a different branch entirely. The run then exercises something real and wrong. **The hazard is the pairing**, not either half alone: a tunnel that outlived its job *and* a name a later job can ask for. Either one on its own is untidy. Together they produce the worst result a test run can produce, which is a pass. ## What it looks like from inside the run Nothing looks broken, and that is the whole problem: - The session is created normally. - The page loads normally, because there is a real host at the other end. - Assertions about structure often pass, because a payroll portal's staging host rebuilt for another branch is still a payroll portal. - Assertions about data fail in ways that read like application bugs — a record that should exist and does not, a total that is off — and the reader spends the morning in the wrong repository. The tell, when there is one, is a **mismatch between what the run believed and what it saw**: the job was for one branch, and the page carries another's identity. That tell exists only if the run asserts identity at the start, which is the cheapest control here. ## Finding one You cannot see a leftover from the pipeline, because the pipeline believes that job is over. Reconciliation is what finds it, and it is a set difference: 1. **What the far side reports as currently up.** 2. **What your pipeline says is live right now.** Anything in the first set and not in the second is a leftover. Names that embed the run identifier make that comparison mechanical rather than a judgement call, because a name belonging to a finished run is recognisable on sight. Run it on a schedule rather than when somebody remembers, and have it report rather than only act, so the rate of leftovers is visible and can be driven down. What the far side does with a path nobody is using — how long it survives idle, whether it is ever closed for you, what it records — is that provider's own behaviour. Establish it by asking and by observing; never design a cleanup strategy around an assumed timeout. ## Preventing one - **Derive a name unique to the job**, so a leftover can never be attached to by a later run. That converts the correctness failure into a tidiness failure, which is a large improvement for little work. - **Register teardown for every exit path**, cancellation included, rather than writing it as the final step. Treat it as best-effort: it reduces leftovers, it does not eliminate them. - **Reconcile on a schedule**, and stop what should not be up. This is the control that catches what teardown structurally cannot: the cases where the runner did not survive to clean up after itself. - **Assert identity at the start of every run**, so a run that did attach to a stale route fails immediately with a message about the target rather than later with a message about a missing record. Two related subjects are deliberately not this one. A standing supplier path into your systems, considered as something to threat-model, is its own discipline, and what an open path consumes while nobody uses it belongs with the consumption model. What this question owns is narrower and more immediate: a route nobody meant to leave open, a later job that can still name it, and a green build that proves nothing.