A hosted browser run that lives on one held-open connection can end at any drop - how do you design around that?

## The run and the connection are the same object When a runner drives a remote browser over one held-open connection, the connection is not transport underneath the run -- it **is** the run. Nothing was minted on the far side that another process could quote. The engine was already running before you arrived and the connection is what ties your work to it, so the moment that connection closes, the thing you were driving is out of reach. This is not a reliability complaint. It is a structural fact that changes which recovery moves are even available, and most of the weak answers to this question propose a move that the shape does not permit. ## What is not available - **Reissuing the command.** A per-command retry assumes the thing you were talking to is still there and still addressable. It is the right move in a request/response arrangement, where a session identifier is a name the remote end keeps. It is not available here, because there is no name to retry against. - **Rejoining from a fresh process.** A new connection to the same address gets you a connection. It does not get you the run you had, unless the service happens to offer re-attachment of its own -- and that is a feature you would have to confirm, not something the shape provides. - **Resuming from a local record.** Your side may know exactly which step it reached. The browser holding the state that step produced is gone, so there is nothing for that knowledge to resume into. ## What is available Recovery moves up a level: the unit you can retry is the whole attachment, and retrying it is a **restart, not a resume**. Everything else follows from deciding how large that unit should be. 1. **Size the failure unit deliberately.** The span of a single attachment is exactly the amount of work a single drop destroys. That makes the span a design parameter rather than an accident of how the harness was written. 2. **Keep each attachment to work that belongs together.** If two batches of scenarios have no reason to share a connection, sharing one only means a drop during the second batch also throws away the first. 3. **Accept the setup cost of shorter spans.** Each attachment pays its own opening. Shorter spans lose less per drop and are exposed for less wall-clock; longer spans amortise the opening. The link's reliability is what should push the choice one way or the other. 4. **Put the retry where it can work.** Wrapping individual browser calls buys nothing against this failure. Wrapping the unit that owns the attachment does. ## The network changes category In a request/response arrangement the network is a dependency of a command: a blip costs the exchange it interrupted. In this arrangement the network is a dependency of the **run**: the same blip can cost everything that attachment was carrying. Link quality therefore stops being a background performance concern and becomes a question about whether your runs finish at all -- which is why a long run over a link you do not trust is a design problem and not a tuning problem. ## What you may not assume about the far side When your socket closes, you learn one thing: your socket closed. You do not learn what the service did next. - Whether it tore the engine down immediately, kept it briefly, or did something else is the provider's business, and a closed connection tells you nothing about it. - Whether anything is still holding your account's capacity, and what the run left behind on the far side, are separate subjects with their own answers; do not guess at them from your own side of a dead socket. - Your own side is the only side you can observe directly, so if you want to know when an attachment opened and when it closed, that has to be recorded by you. ## A worked case A warehouse pick-and-pack console suite runs nightly against a hosted browser. As first written it opens one attachment, walks every picking, packing and dispatch scenario over it, and closes at the end. A single network fault anywhere in that span ends the night's run with most scenarios unreported, and the harness as written records nothing that separates "we lost the link" from "the run stopped". Rewritten, each area of the console gets its own attachment. A fault now costs one area, the rest of the night is unaffected, and the retry the pipeline performs is a restart of that area -- which is a coherent thing to restart, because the attachment's span was chosen to be one. ## The judgment a lead is expected to own The honest framing is a trade, not a defect. A held-open attachment is simple and there is less machinery between your test and the engine. A created-session arrangement is chattier but it is recoverable at command granularity, because the run has a name that outlives any one socket. Which is right depends on how long your runs are, how good the link between your runners and the service is, and what a restart actually costs you. What is not defensible is choosing the first and then designing as though you had the second.