In an Appium dental-recall run, two workers on one host drive the same phone — how do you pin each?

Two workers driving the same handset is not a race condition to tune away. It is a request that never named a target. When a capability map carries no key the platform selects on, two identical maps get the same answer twice, and the run's results belong to a machine nobody chose. ## Read the symptom precisely Before changing anything, separate three situations that look alike from the outside: - Both workers reached the same device because neither map named one. - Both workers reached the same device because both maps named the same one. - The workers reached different devices and interfered through something else the host shares. The first two are this problem and are fixed with selection keys. The third is a different subject — what a parallel worker must hold uniquely beyond its target, including the per-session ports, is owned elsewhere and is not solved by naming a device. ## Pin the Android workers On Android the selecting keys are `appium:udid` and `appium:avd`: - Real handsets in a rack: each worker's map carries its own `appium:udid`, holding the serial adb reports for that handset. - Emulators on a build machine: each worker's map carries its own `appium:avd`, naming a distinct AVD. What will not work is giving each worker a different `appium:deviceName`. The Android drivers accept the key and select on something else, so two maps that differ only there are, for selection purposes, the same map. This is the most common wrong fix, and it is convincing precisely because the maps now look different and the reports now print different names. ## Pin the Apple workers On Apple platforms the keys change with the kind of target: - A real device: `appium:udid` per worker, holding that device's UDID. - A simulator: `appium:deviceName` for the model and `appium:platformVersion` for the runtime, per worker. ## The limit of the simulator pair `appium:deviceName` with `appium:platformVersion` is a description, not an identity. Two simulators of the same model on the same runtime are not separable by it, so a fleet containing identical twins cannot pin them apart with that pair alone. Design around the limit instead of fighting it: give each dental-recall worker a distinct model, or a distinct runtime, so the description is unambiguous for every worker running at the same time. ## Make the pin auditable A pin you cannot prove is a pin you will re-argue during the next incident. For the dental-recall suite that means each run records the key that actually selected, with its value: 1. Android lanes record the `appium:udid` or the `appium:avd` that was sent. 2. Apple real-device lanes record the `appium:udid`. 3. Apple simulator lanes record both `appium:deviceName` and `appium:platformVersion`, because either alone is incomplete. 4. No lane treats `appium:deviceName` on Android as evidence of anything, because it selected nothing there. The failure this prevents is a specific one. A recall-reminder screen fails on one handset in the rack; the report names a device; the team spends an afternoon on the wrong hardware because the report was quoting a key the driver never read. ## A checklist for any lane - Does every worker's map carry a key that selects on that platform? - Is that key's value unique across the workers that run at the same time? - If the value is a description rather than an identity, is the description unique in the fleet? - Does the run record that key and value, rather than the friendliest key in the map? - When a device leaves the fleet, does something fail loudly, or does a stale value quietly land the worker elsewhere? ## What it costs to leave unpinned An unpinned suite is not merely at risk of collisions. It loses the ability to say what its own results are about. Device-specific defects cannot be reproduced, because the device is unknown. Flake cannot be attributed, because the population that produced it changes from run to run. And a green suite is weaker evidence than it appears, since any claim about which hardware was exercised rests on which machines actually ran — which, without a selecting key in every map, nobody can state. The discipline is small and it holds everywhere: one selecting key per worker, unique per concurrent run, recorded with the result.