Found: WP5 gate session, 2026-09-16, leg B of the new 4-leg simulator matrix (docs/testing.md "Which simulator OS — a policy, not a pinned number") — iPhone SE (3rd generation), iOS 17.5.
testExistingBrokerPrefillsFieldsMasksPasswordAndRemoves fails consistently (3/3, including run in full isolation with -only-testing down to the single test) with:
Failed to get matching snapshot: No matches found for Elements matching predicate '"broker.host" IN identifiers'
from input {( TextField 'broker.port', TextField 'broker.username', TextField 'broker.password' )}
broker.port/username/password are present in the queried snapshot but broker.host is not — the opposite of what a normal "hasn't scrolled far enough yet" state looks like, so this looks like the scroll went past broker.host (or its fingerprint-based stop condition in ScrollHarness.swift settled too early on this screen size) rather than a simple timeout.
This is a different failure shape from the already-documented BrokerSetupUITests flake in docs/testing.md ("flakes under full-suite load only, both green 3/3 in isolation" — issues #21/#22 era). This one fails in isolation every time, on this specific device/OS combination. Not reproduced (yet) on iPad Pro 11" M4 / 17.5 (leg A passed clean, including a rerun of the sibling SettingsStorageUITests flake).
ScrollHarness.swift's own doc comment already notes scroll deceleration "is not a stable contract across OS releases — iOS 27 moved it" (issue #50) and was rewritten for that; worth checking whether 17.5 (or the smaller iPhone SE screen, which needs proportionally more scrolling to reach the MQTT section) needs the same treatment.
Not release-blocking on its own (host field prefill/removal is otherwise covered on iPad), but worth root-causing before iPhone SE is used as a real gate leg going forward.
Found: WP5 gate session, 2026-09-16, leg B of the new 4-leg simulator matrix (
docs/testing.md"Which simulator OS — a policy, not a pinned number") — iPhone SE (3rd generation), iOS 17.5.testExistingBrokerPrefillsFieldsMasksPasswordAndRemovesfails consistently (3/3, including run in full isolation with-only-testingdown to the single test) with:broker.port/username/passwordare present in the queried snapshot butbroker.hostis not — the opposite of what a normal "hasn't scrolled far enough yet" state looks like, so this looks like the scroll went pastbroker.host(or its fingerprint-based stop condition inScrollHarness.swiftsettled too early on this screen size) rather than a simple timeout.This is a different failure shape from the already-documented
BrokerSetupUITestsflake indocs/testing.md("flakes under full-suite load only, both green 3/3 in isolation" — issues #21/#22 era). This one fails in isolation every time, on this specific device/OS combination. Not reproduced (yet) on iPad Pro 11" M4 / 17.5 (leg A passed clean, including a rerun of the siblingSettingsStorageUITestsflake).ScrollHarness.swift's own doc comment already notes scroll deceleration "is not a stable contract across OS releases — iOS 27 moved it" (issue #50) and was rewritten for that; worth checking whether 17.5 (or the smaller iPhone SE screen, which needs proportionally more scrolling to reach the MQTT section) needs the same treatment.Not release-blocking on its own (host field prefill/removal is otherwise covered on iPad), but worth root-causing before iPhone SE is used as a real gate leg going forward.