[3.7.0] Espresso IdlingResources + Looper timeouts
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- java
- Domain
- mobile-dev, testing
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.
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.
- Dominant language
- Java
- Stars
- 1.2k
- Forks
- 342
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 7
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from android/android-test
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
android/android-test#681 · 2 comments · 1 reaction ·
-
ξεκσνδξδOpen
Difficulty 5/5 Over a week Newbie friendliness 1/100
android/android-test#2499 ·
-
ησξξσOpen
Difficulty 5/5 Over a week Newbie friendliness 1/100
android/android-test#2498 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
android/android-test#2473 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
android/android-test#2456 ·
All issues in android/android-test
Similar issues
-
new feature
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/rocketmq-dashboard#5594 ·
Maintainers usually reply within 3 days
-
bug pkg:sdk
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
aws/aws-durable-execution-sdk-java#773 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
PCL-Community/PCL-CE#3652 ·
Maintainers usually reply within 1 day
-
TaskSecret.vue: replace explicit `any` with real typesPossibly taken @prayas-bit claimed this today. Openarea/frontend good first issue kind/cooldown
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kestra-io/kestra#20352 · 1 comment ·
Maintainers usually reply within 1 day