e2e: Re-find and retry clicks on stale nodes#6588
Conversation
|
@CodeRabbit review |
PR checklist ✅All required conditions are satisfied:
🎉 Great job! This PR is ready for review. |
✅ Action performedReview finished.
|
WalkthroughAdds a stale-object-safe ChangesUI click reliability
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@stream-chat-android-e2e-test/src/main/kotlin/io/getstream/chat/android/e2e/test/uiautomator/Wait.kt`:
- Line 59: Update the wait-and-click flow around waitToAppear so it passes only
the nonnegative remaining timeout, without using maxOf to add
POLL_INTERVAL_MILLIS after the deadline. Ensure waitToAppear caps its final
sleep to the supplied duration, preserving the same timeout budget and
preventing clicks after timeOutMillis.
- Around line 55-65: Add tests covering Wait.kt’s waitToAppearAndClick behavior:
verify a stale first click is retried and succeeds, repeated
StaleObjectException failures are propagated after the timeout, and retries
never continue past the supplied timeOutMillis deadline. Use controlled timing
or test doubles so the boundary assertions are deterministic.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a014cebf-372c-4301-8b48-8650f2b428ba
📒 Files selected for processing (3)
stream-chat-android-compose-sample/src/androidTestE2eDebug/kotlin/io/getstream/chat/android/compose/robots/UserRobot.ktstream-chat-android-compose-sample/src/androidTestE2eDebug/kotlin/io/getstream/chat/android/compose/tests/AuthTests.ktstream-chat-android-e2e-test/src/main/kotlin/io/getstream/chat/android/e2e/test/uiautomator/Wait.kt
SDK Size Comparison 📏
|
|
1 participant
Goal
test_uploadMultipleImagesfailed all 3 attempts on the 2026-07-24 nightly (run 30059419167, API 34) withStaleObjectExceptionthrown byUiObject2.clickinUserRobot.attachFile. The robots click throughwaitToAppear().click(): the wait helper absorbs staleness while finding the node, but the returnedUiObject2is held across the gap to the click. When the UI refreshes in that gap (the DocumentsUI roots list in this failure, recomposition in the app UI), the click lands on a recycled node and throws. This is the click-path variant of the read-path stale races fixed in #6570.Resolves AND-1326
Implementation
BySelector.waitToAppearAndClick(timeOutMillis)to the shared UiAutomator toolkit (Wait.kt). It waits for the node and clicks it, and when the click throwsStaleObjectExceptionit re-finds the node and retries within the same timeout budget. After the timeout, the exception escapes as before.UserRobot.attachFile(roots button, the Downloads root item where the nightly failed, and the file item).waitToAppear().click()chains in the sample robots and tests (38 call sites in total across both commits). Call sites that use the returned object for other actions (longPress,typeText,clear, reading bounds) keepwaitToAppear().While investigating, the ticket's secondary observation (mock-server logs with no app traffic) turned out to be a misread of the artifacts: each attempt's per-test mock log shows the full login and channel flow, and the retries restarted the app against the fresh mock correctly. Details are on the ticket.
Testing
This changes only e2e test infrastructure, so the e2e suite itself is the test:
test_uploadMultipleImagesandtest_deleteImagestaying clean.Summary by CodeRabbit