[BUG] repeat with while: visible: executes only once instead of looping until element disappears

[7ammer]

Description

repeat with while: visible: only executes once, even when the element remains visible. When deleting items from a list, only one item is removed. Using times: X works correctly.

Steps to Reproduce

1. Run command maestro test my-flow.yaml
2. With flow file (see below)
3. Observe that only one item is deleted and the assertion fails

Expected Behavior

The flow should continue tapping "Delete" while the element is visible, removing all matching items until none remain.

Actual Behavior

The repeat block runs only once. One item is removed, but remaining "Delete" elements are still visible. The final assertion fails.

Environment

• OS: macOS 14.0
• Go version: go1.21.0
• maestro-runner version: 1.0.7
• Executor: UIAutomator2
• Device/Simulator: Pixel 6 API 34 Emulator

Flow File

appId: abc
---
- repeat:
    while:
      visible: "Delete"
    commands:
      - tapOn: "Delete"
- assertNotVisible: "Delete"

Error Output

✓ tapOn (672ms)
✓ repeat (222ms)
  ✓ tapOn (189ms)
✗ assertNotVisible (5.6s)
  ╰─ Element should not be visible but was found

Additional Context

If the same flow uses:

- repeat:
    times: 5
    commands:
      - tapOn: "Delete"

it repeats correctly. The issue appears specific to while: visible:.

[omnarayan]

Thanks for taking the time to report this so thoroughly, @7ammer. We'll get working on it and keep you in the loop.

[omnarayan]

@7ammer Thank you for reporting this and for the detailed reproduction steps — it really helped us track down the issue quickly! 🙌

We've fixed it and also created an interim release so you don't have to wait. You have 2 options:

1. Use the interim release:

curl -fsSL https://open.devicelab.dev/install/maestro-runner | bash -s -- --version 1.0.8-rc1

2. Build from source code

Test Results

Driver	Scenario	Appium taps	Maestro	Result
UIAutomator2	repeat while visible: remove cart items	5 (correct)	3	✅ PASS
DeviceLab	repeat while visible: remove cart items	5 (correct)	3	✅ PASS

Let us know if this resolves it on your end. Really appreciate you helping make maestro-runner better! 💪

[7ammer]

Hi,

Thank you for looking into this so quickly :)

The flow is now repeating. However, after the repeat steps complete the repeat hangs for ~20 seconds (rough estimate) before "completing" the repeat step. My guess here is that it's taking a long time to validate that while: visible: "Delete" is false. I'm unsure if this is by design or not.

I did notice this warning is showing in the logs below. I'm not sure what it means:

⚠ Warning: failed to set implicit wait: unknown command: The requested resource could not be found, or a request was received using an HTTP method that is not supported by the mapped resource

All the logs....

maestro-runner test ./_e2e_/flows/my-flow.yaml

╔═══════════════════════════════════════════════════════════════════╗
║  maestro-runner 1.0.8-rc1 - by DeviceLab.dev                      ║
║  Fast, lightweight Maestro test runner                            ║
║  ⭐ Star us on GitHub                                             ║
╚═══════════════════════════════════════════════════════════════════╝


Setup
────────────────────────────────────────
  ✓ Found 1 test flow(s)
  ✓ Report directory: reports/2026-02-27_13-07-34

Execution
────────────────────────────────────────
  ⏳ Connecting to device...
  ✓ Connected to google sdk_gphone64_arm64 (SDK 34)
  ⏳ Starting UIAutomator2 server...
  → Socket: /tmp/uia2-emulator-5554.sock
  ✓ UIAutomator2 server started
  ⏳ Creating session...
  ✓ Session created
  ⚠ Warning: failed to set implicit wait: unknown command: The requested resource could not be found, or a request was received using an HTTP method that is not supported by the mapped resource

  [1/1] my-flow (my-flow.yaml)
────────────────────────────────────────────────────────────
    ⚠ repeat (25.6s)
    ✓ assertNotVisible: text="Delete" (223ms)
✓ my-flow 25.8s

  [1/1] my-flow (./__e2e__/flows/my-flow.yaml) - Device: google sdk_gphone64_arm64 (android 34)
  ────────────────────────────────────────────────────────────
    ⚠ repeat (25.6s)
      ✓ tapOn (289ms)
      ✓ tapOn (137ms)
      ✓ tapOn (719ms)
      ✓ tapOn (155ms)
      ✓ tapOn (917ms)
      ✓ tapOn (142ms)
    ✓ assertNotVisible (223ms)
✓ my-flow 25.8s

  7 steps passing (25.8s)

════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
  Flow                           Status   Steps   Pass   Fail   Skip   Duration  Device
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  my-flow                     ✓ PASS       7      7      0      0      25.8s  google sdk_gphone64_arm64 (...
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  TOTAL                             1/1       7      7      0      0      25.8s
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════


Device Summary
────────────────────────────────────────────────────────────

Device: google sdk_gphone64_arm64
  Platform: android 34 (Simulator)
  Flows: 1 • Passed: 1 • Failed: 0


  ✓ Tests completed. Generating reports...

  Reports: reports/2026-02-27_13-07-34
    ├── report.json
    ├── report.html
    ├── junit-report.xml
    └── allure-results/

  Paths:
    HTML:   reports/2026-02-27_13-07-34/report.html
    JSON:   reports/2026-02-27_13-07-34/report.json
    JUnit:  reports/2026-02-27_13-07-34/junit-report.xml
    Allure: reports/2026-02-27_13-07-34/allure-results

  Update available: 1.0.8-rc1 → 1.0.7
  Run: curl -fsSL https://open.devicelab.dev/maestro-runner/install | bash

╔══════════════════════════════════════════════════════════════════════════╗
║ Built by DeviceLab.dev - Turn Your Devices Into a Distributed Device Lab ║
╚══════════════════════════════════════════════════════════════════════════╝

[7ammer]

Just ran a similar test. I'm not sure if it's related. If not I can open a new issue.

Here is the flow

- repeat:
    times: 6
    commands:
      - tapOn: "Delete"
- assertNotVisible: "Delete"

Here is the error:

⚠ repeat (7.8s)
✗ assertNotVisible: text="Delete" (10.0s)
  ╰─ Element should not be visible but was found


⚠ repeat (7.8s)
  ✓ tapOn (291ms)
  ✓ tapOn (1.1s)
  ✓ tapOn (2.2s)
  ✓ tapOn (1.0s)
  ✓ tapOn (2.1s)
  ✓ tapOn (1.0s)
✗ assertNotVisible (10.4s)
  ╰─ Element should not be visible but was found

---

The assertNotVisible result is incorrect here. The screen does not show text="Delete" but we get Element should not be visible but was found.

If I run the following flow straight afterwards everything correctly passes:

- assertNotVisible: "Delete"

[omnarayan]

@7ammer for taking 20 secodns, I ll check
for - assertNotVisible: "Delete" one, please log a new issue

[omnarayan]

@7ammer

Fix: Reduce exit delay in repeat-while loops by lowering condition check timeout

Problem

The repeat-while loop was hanging for ~17 seconds after the last iteration. This happened because the condition check (e.g., while: visible) used the full 17-second default timeout to confirm the element had disappeared — even though the loop had already finished its work.

Solution

Condition checks now default to 7 seconds (the optional find timeout) instead of the full 17-second timeout. Additionally, users can set a custom timeout directly in their flow YAML for even faster exit.

Custom timeout options

1. On the condition:

- repeat:
    while:
      visible: "Delete"
      timeout: 2000
    commands:
      - tapOn: "Delete"

2. On the selector:

- repeat:
    while:
      visible:
        id: "my-button"
        timeout: 3000
    commands:
      - tapOn:
          id: "my-button"

Benchmark results

Test scenario: 2 items removed, then condition exits.

Configuration	Repeat duration
Before (17s default)	19.1s
After — no timeout (7s fallback)	8.7s
After — selector timeout: 3000	4.6s
After — condition timeout: 2000	4.1s

How to get the fix

curl -fsSL https://open.devicelab.dev/install/maestro-runner | bash -s -- --version 1.0.8-rc2

[7ammer]

Thanks @omnarayan, I definitely see an improvement which is great too see. Thank you! It's worth noting though that it feels like the underlaying code is waiting for a timeout instead validating that something is no longer visible and then ending the loop at that point.

[7ammer]

FYI: if you're aiming to achieve feature parity with Maestro it appears that using timeout in this way is not a valid.

[omnarayan]

FYI: if you're aiming to achieve feature parity with Maestro it appears that using timeout in this way is not a valid.

Not sure how to maintain parity — my idea is to give users more fine-grained control. I'm trying to support all Maestro commands and parameters as the baseline, but I can't really go beyond that without adding more on top.
Need help / suggestions.