Repository navigation
Conversation
This was referenced Sep 29, 2026
bulatgaleev
force-pushed
the
upstream-pr/wda-launchapp-stops-first
branch
from
September 29, 2026 18:31
f93a29f to
e74d507
Compare
This was referenced Sep 29, 2026
bulatgaleev
force-pushed
the
upstream-pr/wda-launchapp-stops-first
branch
from
September 30, 2026 01:41
e74d507 to
6b52428
Compare
The WDA driver reads an element's name, rect, text and displayed in parallel, and a tap looks an element up four ways at once. The client used Go's default transport, which keeps two idle connections per host, so every such burst closed two connections and opened two new ones. On a real iPhone reached through a forward (SSH, then iproxy over USB) a new connection costs about 300 ms, and new ones opened together fail at once with EOF. In one 44-flow run, 297 of 996 element bursts lost exactly two reads (the two new connections), 2 lost one, and none lost a read on a kept connection: 976 EOFs, each sent again by the dropped-connection retry. WebDriverAgent does not close an idle keep-alive connection (FBHTTPServer exempts them from its reaper), so a stale reuse was not the cause. The client now keeps up to eight idle connections per host. In the new tests, 50 bursts of four reads open 4 connections instead of 102, and through a server that drops every new connection past the first four, no read fails (the old client lost 23 reads there, after 196 dropped connections).
Maestro runs a retry's commands once and then up to maxRetries more times:
`(maxRetries?.toIntOrNull() ?: 1).coerceAtMost(3)`, then
`while (attempt <= maxRetries)` from 0 (Orchestra.kt:934-955, with
MAX_RETRIES_ALLOWED at 1844 and the "1" default at YamlFluentCommand.kt:614).
So `maxRetries: 1` is two attempts, the default is two, and no retry runs
more than four times. The value is evaluated first, so ${...} works
(Commands.kt:986), and anything that is not an integer counts as 1.
The runner ran exactly maxRetries attempts, three when unset, with no cap,
so a flow written with `maxRetries: 1` never retried at all. It also failed
the step when maxRetries was not an integer. The inline and the file form
of retry now count as Maestro does. A negative maxRetries runs no attempt
and passes, since Maestro's loop never starts. A value that is not an
integer is logged and read as 1.
Maestro stops the app before launching it unless the flow says `stopApp: false`. The WDA driver never read stopApp: with a session open and no launch arguments it called WDA's launch on the running app, which only activates it. A relaunch then left the app on the screen it was already on, so a flow checking what survives a restart (a chat's history, or a changed subscription state being read back on launch) was not restarting anything. It now terminates first unless stopApp is false. Launch arguments still force the stop, since they only apply on a real launch. A launchApp that creates the session is unchanged: creating it launches the app fresh.
bulatgaleev
force-pushed
the
upstream-pr/wda-launchapp-stops-first
branch
from
September 30, 2026 14:49
6b52428 to
9b05a9b
Compare
Contributor
|
Thank you @bulatgaleev. Agreed, this matches Maestro: It is a behaviour change for WDA flows that relied on |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Maestro stops the app before launching it unless the flow says
stopApp: false. The WDA driver never readstopApp: with a session open and no launch arguments, it called WDA's launch on the running app, which only activates it. A relaunch left the app on the screen it was already on, so a flow checking what survives a restart was not restarting anything. The driver now terminates the app first unlessstopAppis false.Type of Change
Changes Made
launchAppon an open session terminates the app before launching it, unlessstopApp: false.launchAppthat creates the session is unchanged: creating the session launches the app fresh.pkg/driver/wda/launch_stop_test.go, and a CHANGELOG.md entry.Related Issues
No existing issue found.
Testing
go test ./pkg/driver/wda/go vet ./...andmake fmt-checkpass (run on the top of the stack, fix(wda): checked selectors work on iOS #185, which contains all five changes)make testas a whole: not run, because its device tests drive whatever device is attached to the machinemake lint: the Makefile has nolinttarget, and the lintersmake checkruns (staticcheck, revive, errcheck, nilaway, gosec) are not installed hereChecklist
Additional Notes
A
launchAppwithoutstopApp: falsenow restarts a running app, as it does under Maestro. A flow that meant to bring the app forward without restarting it can saystopApp: false.Stack 3 of 5: #181 → #182 → #183 → #184 → #185. Merge in that order. This branch is built on #181 and #182, so it also contains their commits. This PR's own change is the top commit,
9b05a9b. Once the PRs below it merge, the rest of the diff disappears, and nothing conflicts. All five sit onmainatfe3dd53(the 1.1.28 release).