[BUG] Some random issues in 1.0.8

[maraujop]

Hi there,

First congratulation on the approach you are using for this runner, I find it really interesting. It is faster and some things work more reliably than in maestro studio.

I experienced with it for a couple of days and I would like to talk about my experience with it.

1. Sometimes tapOn text taps on things that are not visible in the screens, I avoided this by using tapOn id.

2. Sometimes tapOn claims to have tapped on something, but it probably taps that thing too early and no action happens after. The runner reports it as tapped correctly, however the UI doesn't change.

3. For previous situation I tried to use waitForAnimationToEnd but it didn't help (most of the times is a 0ms or 1ms run), I was able to workaround this by doing assertVisible that force the UI to stabilize.
   This particularly happens after bottom sheet animations and trying to tap an element of that bottom sheet.

Suggestion: Although I understand you want to be 100% compatible api with official maestro yamls, I think you have a great chance of adding new features. For example, adding a custom timeout to runFlow when would be great for us.

All tests were run with latest maestro-runner 1.0.8 (which worked far better than 1.0.7 fixing a few issues I had) and iOS 26.1 in a simulator of iPhone 17. None of these tests had nothing particularly special, but if you think a recording could help, I can provide it.

[omnarayan]

@maraujop — thank you for the honest feedback. For any tool to become truly good, we need exactly this kind of input. It really means a lot that you took out your valuable time to give such constructive feedback.

Please don't take the following as me brushing off your issues, I'm going to work on all of them. The following are just workarounds to help you out while we work on proper solutions (with the acknowledgment following workaround might not work for you).

For points 2 and 3 — try maestro-runner --wait-for-idle-timeout 10000 test flows/ — here you can control the delay, and you can also control this per step in the YAML file.

Now, back to your suggestion of adding timeout to the runFlow step — wouldn't it be better to add it to all steps? That way runFlow would also be covered, and users can set it for any step they need.

We actually do have timeout support for all steps, but due to a limited understanding of the use cases, I hadn't added it to runFlow steps. I'm not trying to justify that I made the right call, just explaining the reasoning behind it. I thought that since timeout was already applied to each individual step, and runFlow operates within that time, it was covered. Clearly it wasn't, and this will be added to runFlow.

# Custom 30s timeout — waits up to 30s to find this element
  - tapOn:
      text: "Welcome Dashboard"
      timeout: 30000

  # Custom 5s timeout on an assertion
  - assertVisible:
      text: "Profile"
      timeout: 5000

  # Optional step with custom timeout (default optional is 7s)
  - tapOn:
      text: "Skip Tutorial"
      optional: true
      timeout: 3000

---

One last thing

As the default driver we are using the Appium UIAutomator2 server. We also built our own Android driver, this is optional, but I'd like you to give it a try; it might be much faster, more reliable, and have a few tricks up its sleeve

How to use it: maestro-runner --driver devicelab --platform android test flow.yaml

[maraujop]

Thanks a lot for your kind words @omnarayan I'm happy we agree so much on how an open source project can get better.

For points 2 and 3 — try maestro-runner --wait-for-idle-timeout 10000 test flows/ — here you can control the delay, and you can also control this per step in the YAML file.

I tried this with no effect at all. As soon as I remove my assertVisible test breaks, because it thinks it has been tapped and it's moving along, but no.

Honestly with the assertVisible workaround I'm getting by, sometimes might not be bad to assert more often :)

We actually do have timeout support for all steps

Sorry, how do you use that? I think it would be good enough for our usecase.

I'm planning on testing this in Android maybe next week, I will keep you posted with impressions for sure.

Kudos and keep up the good work 👍

[omnarayan]

@maraujop We've added runFlow timeout support. Here's how to use it:

---

File-based runFlow with timeout (milliseconds):

- runFlow:
    file: common/login.yaml
    timeout: 5000
    env:
      username: devicelab

Inline runFlow with timeout:

- runFlow:
    timeout: 3000
    commands:
      - tapOn: "Submit"
      - assertVisible: "Success"

---

One thing worth knowing: the timeout propagates into driver polling loops. So if an element search is mid-execution when the timeout fires, it gets interrupted right then — it won't sit and wait out the full default polling window first.

Error messages try to be specific about what actually timed out:

runFlow 'common/login.yaml' timed out (2s timeout)
runFlow timed out (3s timeout) while executing: assertVisible: text="THIS_ELEMENT_DOES_NOT_EXIST"
element "Username" not found: runFlow timeout (2s) exceeded

Timeout failures show up as TIMEOUT type in HTML, JUnit, and Allure reports.

---

The change is on the feat/runflow-timeout branch. Build from source or grab the interim build:

curl -fsSL https://open.devicelab.dev/install/maestro-runner | bash -s -- --version 1.0.9-rc.1

Would love to get more feedback and suggestions

[maraujop]

Ok, not sure if we are on the same page, I used the word timeout, which might not be the most accurate in this usecase

- runFlow:
    timeout: 3000
    when: 
        visible: "Turn on your notifications"
    commands:
      - tapOn: "Submit"
      - assertVisible: "Success"

What I want here is that the runflow only waits for 3 seconds for the condition to happen, maybe better named would be

- runFlow:
    waitForCondition: 3000
    when: 
        visible: "Turn on your notifications"
    commands:
      - tapOn: "Submit"
      - assertVisible: "Success"

[omnarayan]

@maraujop - I should have asked more questions before jumping to writing code :)

This looks like an interesting use case, with one change — since the same flow might have multiple conditions, I'm not making a decision yet, just discussing.
waitForCondition moved inside while, so multiple conditions can each have their own timeout.

- runFlow:
    when: 
        waitForCondition: 3000
        visible: "Turn on your notifications"
    commands:
      - tapOn: "Submit"
      - assertVisible: "Success"

    when: 
        waitForCondition: 2000
        visible: "Turn off your notifications"
    commands:
      - tapOn: "Submit"
      - assertVisible: "Success"

[omnarayan]

@maraujop If you're looking for a similar pattern, something like this already exists — and apologies if I'm still not fully understanding the requirements

# "Enable Notifications" doesn't exist — should wait ~2s then skip.
  - runFlow:
      when:
          visible: "Enable Notifications"
          timeout: 2000
      commands:
        - tapOn: "Allow"