android / android/android-test
[3.7.0] Espresso IdlingResources + Looper timeouts
- Dominant language
- Java
- Stars
- 1.2k
- Forks
- 342
- Avg merge
- 11h 29m
- Merged PRs (30d)
- 2
Description
In 3.7.0 (this didn't happen in 3.6.x) we started getting idling resource timeouts for the loopers registered with `registerLooperAsIdlingResource`. It's unclear why they are suddenly timing out since calling `dump()` shows no queues messages/tasks.
However, things are hard to debug because `androidx.test.espresso.base.Interrogator` replaces the default queue handling with its own less realistic `loopAndInterrogate` impl. As a result, we can't use things like `Looper.setMessageLogging` as that config is ignored by the internal `Handler` of `Interrogator`. I also question whether `loopAndInterrogate` is correct, since when i don't call `registerLooperAsIdlingResource` the output of `dump` is different (and the message logging works), while ideally it should be the same.
Likely not useful, but here's an example stack-trace:
```
01-10 21:37:12.126 12249 12279 E TestRunner: androidx.test.espresso.IdlingResourceTimeoutException: Wait for [LooperIdlingResource-88-epoxy, LooperIdlingResource-87-FooWorkerThread] to become idle timed out
01-10 21:37:12.126 12249 12279 E TestRunner: at dalvik.system.VMStack.getThreadStackTrace(Native Method)
01-10 21:37:12.126 12249 12279 E TestRunner: at java.lang.Thread.getStackTrace(Thread.java:1960)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.base.EspressoExceptionHandler.handleSafely(EspressoExceptionHandler.java:34)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.base.EspressoExceptionHandler.handleSafely(EspressoExceptionHandler.java:26)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.base.DefaultFailureHandler$TypedFailureHandler.handle(DefaultFailureHandler.java:158)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.base.DefaultFailureHandler.handle(DefaultFailureHandler.java:120)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.ViewInteraction.waitForAndHandleInteractionResults(ViewInteraction.java:385)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.ViewInteraction.desugaredPerform(ViewInteraction.java:212)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.ViewInteraction.perform(ViewInteraction.java:140)
01-10 21:37:12.126 12249 12279 E TestRunner: at androidx.test.espresso.Espresso.closeSoftKeyboard(Espresso.java:206)
```
I suspect it's a regression in 3.7.0, but if not, it would be nice to include more debugging info in the error about what task(s) are beleived to make the handler/looper not idle and also unclear dump() and setMessageLogging.
Contributor guide
Research direction
Start with androidx.test.espresso.base.Interrogator, especially loopAndInterrogate, and trace how registerLooperAsIdlingResource changes Looper handling in 3.7.0 versus 3.6.x. Compare dump() and Looper.setMessageLogging behavior with and without the registration, using the reported timeout as the reproduction; done means identifying or fixing the regression, or exposing enough task and handler state to explain the timeout.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- mobile-dev, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100