You attach Appium Inspector to a live locksmith call-out session to chase a flake — what does that attachment change about the session?

## The Inspector is a client, not a lens Appium Inspector does not run on the device and it is not part of any driver. It is a WebDriver client — the same kind of thing your test framework is — holding an HTTP conversation with a running Appium server. When you choose *attach to session* rather than letting it create one, you end up with two clients issuing commands against a single session, and nothing in the protocol marks one of them as a read-only observer. The server answers whoever asks. That is the whole of the surprise, and it is why an Inspector attached to a locksmith call-out session is an instrument that perturbs what it measures. ## What one refresh puts on the wire Redrawing the two panes is neither free nor cached. A refresh issues real commands down the same driver to the same device: - A screenshot request, so the left pane can draw the current screen - A page-source request, so the right pane can draw the element tree - A find per candidate strategy whenever the suggested-locator table shows timings, because a measured timing means the Inspector actually ran that lookup against the live session So the numbers in the suggestion table are not estimates from a model of the app. They are the wall-clock cost of finds the Inspector performed on *your* session, on that screen, a moment ago. ## Every Inspector action is a real action The screenshot pane is interactive, and that interactivity is not simulated: | What you do in the Inspector | What reaches the session | What the device does | |---|---|---| | Press refresh | Screenshot and page-source commands | Nothing changes on screen | | Tap a point or a selected element | A real pointer action | The app responds as it would to a user | | Send keys to a field | A real value command | The field takes the text | | Time the suggested locators | One find per candidate | Nothing changes, but time passes | The middle column is the point. If you tap *Dispatch* in the Inspector to see what the next screen looks like, the locksmith call-out app is now on the next screen — for your suite too. A test parked on a breakpoint believes it left the app on the job-details screen; it is now on the dispatch confirmation, and the next line of the test fails for a reason that has nothing to do with the bug you were chasing. ## Why a dying session survives while you browse Sessions are deleted after an idle period, governed by `newCommandTimeout`. *Idle* means no commands, and Inspector traffic is commands. Every refresh, every tap, every timed suggestion resets that clock. The practical effect is that a session which would have expired mid-investigation lives exactly as long as you keep clicking — and then dies the moment you stop, often while you are reading the tree and wondering why the next refresh errors. Nothing is broken; the instrument was the only thing keeping the patient breathing. ## What this costs a flake investigation - The screen you are reading is the screen after your own Inspector taps, not the screen at the moment of failure - Timings in the suggestion table were measured under Inspector load, on a device that is also serving your suite - Attaching to a session a parallel worker owns puts two clients' worth of intent on one device - A locator verified only through the Inspector was verified against a capture, not against the app as your test reaches it - On a shared or hosted server, the session you attach to may not be yours to disturb at all ## Working with the instrument, not against it 1. Decide *before* attaching whether this session is disposable. If it is the one that failed, expect to spend it. 2. Refresh once and reason from that single capture rather than clicking through the app inside the Inspector. 3. Reproduce the failure with the Inspector detached before you believe a fix, so the timing profile is the suite's and not the tool's. 4. For exploration, let the Inspector start its own session from capabilities instead of attaching to a running one — a session created for inspection is one you are free to ruin. 5. When you must attach to a live run, tell whoever owns that run; the device is not yours alone. The Inspector answers *what does the tree contain right now* faster than anything else you have. It is a poor witness for *what did the tree contain when the test failed*, because the second question needs an observer that does not touch the thing it observes — which this one, by construction, is not.