Skip to content

fix(wda): launchApp stops a running app first unless stopApp is false - #183

Merged
omnarayan merged 3 commits into
devicelab-dev:mainfrom
vyrahealth:upstream-pr/wda-launchapp-stops-first
Oct 1, 2026
Merged

omnarayan merged 3 commits into
devicelab-dev:mainfrom
vyrahealth:upstream-pr/wda-launchapp-stops-first

Conversation

@bulatgaleev

@bulatgaleev bulatgaleev commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Summary

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 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 unless stopApp is false.

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update
  • Refactoring (no functional changes)

Changes Made

  • launchApp on an open session terminates the app before launching it, unless stopApp: false.
  • Launch arguments still force the stop, since they only apply on a real launch.
  • A launchApp that 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/
  • Added tests for new functionality
  • Running on a physical iPhone (iOS 27, WebDriverAgent reached through a forwarded port) in our nightly 46-flow suite, as part of our fork's build
  • go vet ./... and make fmt-check pass (run on the top of the stack, fix(wda): checked selectors work on iOS #185, which contains all five changes)
  • make test as a whole: not run, because its device tests drive whatever device is attached to the machine
  • make lint: the Makefile has no lint target, and the linters make check runs (staticcheck, revive, errcheck, nilaway, gosec) are not installed here

Checklist

  • Code follows project style guidelines
  • Self-reviewed the code
  • Added/updated documentation as needed (no documentation change needed)
  • No breaking changes (or documented if breaking)
  • CHANGELOG.md updated (for notable changes)

Additional Notes

A launchApp without stopApp: false now restarts a running app, as it does under Maestro. A flow that meant to bring the app forward without restarting it can say stopApp: 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 on main at fe3dd53 (the 1.1.28 release).

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
bulatgaleev force-pushed the upstream-pr/wda-launchapp-stops-first branch from 6b52428 to 9b05a9b Compare September 30, 2026 14:49
@omnarayan

Copy link
Copy Markdown
Contributor

Thank you @bulatgaleev. Agreed, this matches Maestro: launchApp stops the app first unless stopApp: false, and a relaunch that only brought the app to the front was not testing a restart.

It is a behaviour change for WDA flows that relied on launchApp resuming the running app, so it will be noted in the release notes. Merging into main now; it ships in 1.1.29.

@omnarayan
omnarayan merged commit 3267d2b into devicelab-dev:main Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants