How does a run that attaches to a running remote browser differ from one that creates a session?

## Two arrangements behind one phrase "Point the client at a remote endpoint" describes two quite different arrangements, and a suite behaves differently depending on which one it is actually using. The **created-session** arrangement is the one the W3C WebDriver specification describes. The client sends a new-session request to the remote end. The remote end reads that request, decides whether it can serve it, and if it can, it mints a **session identifier** and returns it. Every later action -- navigate, click, read text -- is a separate exchange addressed to that identifier. The run ends when something deletes the session, or when the remote end ends it after inactivity or for reasons of its own. The **attachment** arrangement creates nothing. An engine is already running on the far side. The runner opens a single duplex connection to it and drives it over that one connection for the rest of the run. There is no request to match, no identifier handed back and no delete to send. The run ends when the connection ends. Both put the browser somewhere other than the machine that started the suite, which is why they get described in the same words. Underneath, they differ in three ways that matter. ## What names the run This is the sharpest difference, and the one most interview questions are aiming at. - In the created-session arrangement the name is the session identifier, and the **remote end keeps it**. It is not a property of any particular socket, so a client that reconnects can address the same session again, and a client that disappears leaves the session standing until something ends it. - In the attachment arrangement the name **is the connection**. Nothing was minted that another process could pick up. If the connection goes, there is no handle to come back to -- unless the service offers re-attachment of its own, which is a feature it may or may not have rather than something this shape gives you. Two consequences follow directly: 1. A transient network fault has a different blast radius in each arrangement. Against a created session it costs the exchange it interrupted, and the session on the far side is usually still there and still addressable by name. Against an attachment it can cost the whole run. 2. Cleanup means different things. One arrangement has an explicit end that you can forget to send. The other has an end that happens whether you ask for it or not. ## Where the configuration goes A created session carries its configuration in the new-session request: the client describes what it wants, and the remote end matches it or refuses. That payload is the natural home for anything the far side must be told. An attachment has no such payload. The engine's identity -- which build, on which platform -- was settled before the runner arrived rather than negotiated when it connected. So anything the far side must know at connect time has to be carried by the address you connect to, or agreed beforehand. The precise form of that address, and the account credential commonly carried inside it, is a subject of its own. The point here is narrower: a negotiated map has nowhere to live, so the address takes on work that would otherwise have travelled in a request body. That also changes how you ask for something different. Where a created session asks for another browser by changing what it requests, an attachment asks by connecting somewhere else. ## What the runner still has to hold Because you are joining an engine that already exists, there is no engine build for the runner to fetch and nothing on the runner that has to be kept matching one. What remains is the client library, the address, and whatever your own tests depend on. Attaching moves the platform off your machine; it does not move the harness. ## Reading the difference in a real suite Take a warehouse pick-and-pack console as the application under test. Two runs of the same suite can look identical in the report and be built completely differently: - One creates a session per scenario, so a scenario interrupted by a network hiccup loses a command and can be examined on its own. - The other holds a single attachment across a batch of scenarios, so the same hiccup ends the batch, and the report shows work that neither passed nor failed. Neither is wrong; they fail in different places. What you should not do is reason about one arrangement while running the other -- that is where "just add a retry" comes from, and it is why the retry does not help a run that lost its connection. ## The short version | | created session | held-open attachment | |---|---|---| | how it starts | a request the remote end matches or refuses | a connection to something already running | | what names the run | an identifier the remote end keeps | the connection itself | | where settings travel | the new-session request payload | the address, or agreed beforehand | | what ends the run | a delete, an idle timeout, or the remote end | the connection closing | | after a drop | the session usually still has a name | nothing was minted to return to |