A hosted browser provider updated the browser build under your seat-reservation suite overnight. What can you still control?

## What you gave up when you stopped installing Pinning a browser is a property of **installing** one. On a fleet you operate, a browser build and its matching driver are present because somebody put them there — in a machine image, a package pin, a container tag — and the build that runs tomorrow is the build committed today. Changing it is a change: reviewed, rolled out, and revertible the way any other infrastructure change is revertible. Renting removes the install, and it takes the pin with it. The machine estate belongs to the provider, so the estate's refresh cadence belongs to the provider too. A browser vendor ships; the provider takes the new build into its fleet on its own timetable; and one morning a page of your seat-reservation suite that has been green for months is red — not because the application moved, not because the test is wrong, but because the platform underneath both of them moved. ## What you still control, precisely The honest answer here is narrower than either of the confident ones. You have not lost everything, and you have not kept much. - **You can ask for a target instead of accepting a default.** A session request names what it wants. A suite that asks for a specific browser and platform is at least explicit about what it expects, rather than silently inheriting whatever the far side treats as current. - **You can record what you were actually given.** A created session reports the environment that was created for it. A suite that writes that into its run record can answer "what was different last night" the next morning, instead of reasoning from memory. - **You can compare against something you do control.** Running the same case in an environment you own — even a narrow one — converts an unanswerable "did the platform change?" into a difference you can read off two results. - **You can raise it with the provider as a specific run**, which only works if you kept the identifiers that make a run specific while it was still alive. ## What you do not control, and should not claim to - The provider's estate does not roll back for you. There is no revert commit on a machine you do not administer. - Whether older builds stay available at all, and for how long, is a property of that provider. **Establish it; never assume it.** A suite that quietly depends on an older build remaining on offer has taken a dependency nobody wrote down, and it discovers that dependency at the worst moment. - You cannot reconstruct the far-side host locally. You can approximate a browser build; you cannot approximate everything else on a machine you have never seen — its fonts, its display geometry, its locale, its clock, the load it was under. ## The overstatements to avoid Both directions get stated too strongly, and an interviewer is listening for the hedge: 1. **"You cannot pin anything on a rented fleet."** Not true. A request can name a browser and a platform, and a provider that offers them will honour a request it understands. What you cannot do is guarantee the named target stays on offer, or that everything else on that host is what it was last week. 2. **"Just ask for the newest and stay current."** That is a decision to accept every upstream change on somebody else's timetable, with your suite as the detector. It is a legitimate choice for a fast-moving product, but it should be a choice somebody made rather than a default nobody noticed. ## Turning the surprise into a signal A platform refresh that reddens a suite is not only a nuisance; it is information. A browser vendor changed something, and your application met that change before your users did. Teams that get value out of a rented fleet treat the morning after a refresh as triage with a named starting hypothesis: - Did the same case pass in an environment you control? If it did, the platform is implicated rather than the code. - Did unrelated cases fail together in a structural way — layout, timing, a dialog, a download — rather than a single assertion drifting? - Does the recorded environment for last night's run differ from the night before's? - Did the failure arrive at a boundary in time rather than gradually, which is what an estate refresh looks like and what a slow application regression does not? ## Designing so the surprise is cheap The point of all this is not to eliminate the surprise, which you cannot, but to make it inexpensive: 1. **Request targets explicitly.** Make the expected browser and platform an artefact of the suite rather than a property of the fleet. 2. **Record the environment you were given, every run.** It costs nothing and it is the closest description of that machine you will hold. 3. **Keep a small lane you own.** It need not be broad; it needs to be a control group. 4. **Write down which targets the suite depends on**, and treat their continued availability as a question for the provider rather than an assumption. The underlying idea generalises well beyond browsers: **when you stop operating a thing, you stop being able to freeze it.** Renting buys you out of the upgrade treadmill and simultaneously buys you out of the upgrade decision, and those are the same transaction seen from two sides.