[BUG] scrollUntilVisible fails when run inside repeat

[7ammer]

Description

scrollUntilVisible fails when used inside a repeat block if the tapped element changes its text from "Favourite" to "Unfavourite". The first iteration succeeds, but subsequent iterations time out and tapOn fails with no such element.

The same commands work correctly when written sequentially outside of a repeat block.

Steps to Reproduce

1. Run command maestro test my-flow.yaml
2. With flow file (see below)
3. Observe failure inside repeat after the first iteration

Expected Behaviour

Each iteration should:

1. Execute scrollUntilVisible for "Favourite"
2. Tap "Favourite"
3. Repeat successfully for the configured number of times

Actual Behaviour

The first iteration succeeds. On the second iteration:

• scrollUntilVisible runs but eventually times out
• tapOn fails with no such element
• The repeat block fails with context deadline exceeded

Environment

• OS: macOS (darwin/arm64)

• Go version: go1.26.0

• maestro-runner version: 1.0.8-rc2

  • Commit: b01ce7d
  • Built: 2026-02-27T14:52:52Z

• Executor: UIAutomator2

• Device/Simulator: Pixel 6 API 34 Emulator

Flow File

appId: abc
---
- repeat:
    times: 3
    commands:
      - scrollUntilVisible:
          element: "Favourite"
      - tapOn: "Favourite"

Error Output

✗ repeat (41.6s)
    ╰─ Element not found: context deadline exceeded: no such element: An element could not be located on the page using the given search parameters
    ✓ scrollUntilVisible (3.4s)
    ✓ tapOn (243ms)
    ⚠ scrollUntilVisible (20.1s)
    ✗ tapOn (17.3s)
      ╰─ context deadline exceeded: no such element: An element could not be located on the page using the given search parameters

[omnarayan]

@7ammer Thank you for reporting it, we'll look into it and get it sorted.

[omnarayan]

@7ammer need you help

• How many "Favourite" items are in the list? After tapping one and it becomes "Unfavourite", is there still another "Favourite" below to scroll to?
• Does the list re-sort when you toggle favourite/unfavourite?
• When you say it works sequentially — you mean writing scrollUntilVisible + tapOn three times without repeat? Can you share that flow?
• A short screen recording of both cases would really help

[7ammer]

He @omnarayan!

1. In this scenario there is a very large list of items. Each item has a height of roughly 2/3rds of the screen. In each item there is a button to "favourite/unfavourite". Only one or two "favourite" toggle buttons can be visible at a time on the screen on a typical pixel phone. As you scroll, more items will be revealed. For this test all items will be originally set to the default value of "favourite".
2. No, the items stay in the same position. Only the toggle state changes from "favourite" to "unfavourite"
3. Yes, apologies! I meant to include this in the original message. This works without issue and is effectively the same thing, just written without repeat:

- scrollUntilVisible:
    element: "Favourite"
- tapOn: "Favourite"
- scrollUntilVisible:
    element: "Favourite"
- tapOn: "Favourite"
- scrollUntilVisible:
    element: "Favourite"
- tapOn: "Favourite"

4. I unfortunately cannot provide this for the project I'm working on but if the above is not helpful I can work up demo and record that. It will take me a while.

[omnarayan]

@7ammer took a stab at this.

The root cause turned out to be pretty straightforward: step.MaxScrolls and step.TimeoutMs were getting parsed from YAML just fine, but never actually wired into the driver loop. All 4 drivers (UIAutomator2, WDA, Appium, DeviceLab) had their own hardcoded scroll limits (10 or 20) with no way to override them from the flow file.

What changed (bb1ca90):

All drivers now share the same dual-condition loop:

maxScrolls = step.MaxScrolls if > 0, else 20 (default)
timeout    = step.TimeoutMs  if > 0, else 30s (default)

loop while: i < maxScrolls AND now < deadline

So you can now do:

- scrollUntilVisible:
    element:
      text: "Sign Out"
    direction: "down"
    maxScrolls: 5
    timeout: 10000

And inside a repeat block (which was the original issue):

- repeat:
    times: 3
    commands:
      - scrollUntilVisible:
          element:
            text: "Sign Out"
          direction: "down"
          maxScrolls: 5
          timeout: 10000

---

Honest caveat: unit tests pass and we validated scrollUntilVisible (by text) on a real Android device with both UIAutomator2 and Appium drivers — that works. But we haven't been able to reproduce the exact repeat + scrollUntilVisible

---

I have created an interim build, you can use it or compile from source:

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

We also recently added a new driver called DeviceLab — still in beta but it's noticeably faster and might side-step the issue entirely. Worth a try if you're open to it.

To use it with the new driver:

maestro-runner --driver devicelab --device <DEVICE_SERIAL> test <flow.yaml>