test(e2e): harden recording and outgoing-call waits against backend latency

[PratimMallick]

Goal

Closes AND-1323

Two demo-app E2E tests fail deterministically on develop (and on any PR that runs the Test compose shard) because the tests assume the backend produces UI state faster than it actually does:

• ParticipantActionsTests.testParticipantRecordsCall
• RingingTests.testUserRejectsTheOutgoingAudioCall

Both surfaced as java.lang.NullPointerException: findObject(...) must not be null when a waitToAppear timed out before the expected element rendered. Captured logcats confirmed the SDK receives and handles the relevant events correctly (CallRecordingStartedEvent / CallRecordingStoppedEvent) — the failures are purely test-timing assumptions vs. backend latency.

Root cause of the recording test: the composite recorder takes ~10-15s to spin up before it emits call.recording_started. The buddy was told to record for only 15s, so ~10s of spin-up left just a ~5s client-visible window — which closed before the 3-view assertion loop (GRID, DYNAMIC, SPOTLIGHT) could observe the recording icon. No timeout increase can fix a window that has already closed, so the real fix is to record long enough that the icon is reliably observable.

Implementation

All changes are confined to demo-app/src/androidTestE2etestingDebug — no production/SDK code is touched.

Recording test (testParticipantRecordsCall) — the core fix:

• Record for 60s (was 15s) so the icon is reliably visible across all three views after the ~10-15s spin-up.
• Keep the buddy in the call for 120s via setCallDuration(120) (buddy default is 30s) so the 60s recording runs to completion instead of being cut off when the buddy leaves — mirrors the existing ReconnectionTests pattern.
• assertRecordingView(isDisplayed = false) icon-disappear wait 5s → 70s, since the recording now runs ~60s before call.recording_stopped. waitToDisappear returns as soon as the icon is gone, so the longer timeout is only fully spent while recording is still running.
• acceptCallRecording() / declineCallRecording() consent-dialog wait 10s → 30s — the dialog only appears on call.recording_started (~10-15s in).
• assertRecordingView(isDisplayed = true) icon-appear wait 5s → 30s.

Ringing test (testUserRejectsTheOutgoingAudioCall):

• assertOutgoingCall(isDisplayed = true) decline-button wait 10s → 20s — the outgoing ringing screen only renders after the call create/ring network round-trip, which can exceed 10s under CI load.

Testing

• Test compose shard on CI — testParticipantRecordsCall and testUserRejectsTheOutgoingAudioCall now pass
• ./gradlew :demo-app:spotlessApply — formatting clean
• Change is test-only (UI-automation waits + buddy recording duration); no unit-test or SDK behavior affected.

☑️Contributor Checklist

General

• I have signed the Stream CLA (required)
• Assigned a person / code owner group (required)
• Thread with the PR link started in a respective Slack channel (required internally)
• PR targets the develop branch
• PR is linked to the GitHub issue it resolves

Code & documentation

• Changelog is updated with client-facing changes (N/A — test-only change)
• New code is covered by unit tests (N/A — E2E test hardening)
• Comparison screenshots added for visual changes (N/A — no UI change)
• Affected documentation updated (KDocs, docusaurus, tutorial) (N/A)
• Tutorial starter kit updated (N/A)
• Examples/guides starter kits updated (stream-video-examples) (N/A)

☑️Reviewer Checklist

• Bugs validated (bugfixes)
• New feature tested and works
• Check the SDK Size Comparison table in the CI logs

[github-actions]

PR checklist ✅

All required conditions are satisfied:

• Title length is OK (or ignored by label).
• At least one pr: label exists.
• Sections ### Goal, ### Implementation, and ### Testing are filled, or the PR is bot-authored.
• An issue is linked (Linear ticket or GitHub issue), or the PR is bot-authored.

🎉 Great job! This PR is ready for review.

[coderabbitai]

Walkthrough

The E2E call assertions now allow longer waits for the recording indicator and outgoing-call decline button to accommodate delayed UI rendering.

Changes

E2E UI assertions

Layer / File(s)	Summary
Extended UI appearance timeouts demo-app/src/androidTestE2etestingDebug/kotlin/io/getstream/video/android/robots/UserRobotCallAsserts.kt	Recording view appearance waits up to 30 seconds, and the outgoing call decline button waits up to 20 seconds when expected to be visible.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Poem

A rabbit watched the call screen glow,
“Wait a little longer,” said he so.
Thirty seconds for recording’s sign,
Twenty for decline to align.
CI hops onward, smooth and bright—
The UI appears just right.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly matches the PR’s main change: increasing E2E waits to handle backend latency.
Description check	✅ Passed	The description includes Goal, Implementation, Testing, and checklist details, with only non-critical UI/GIF sections missing.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test/e2e-recording-ringing-wait-hardening

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

SDK Size Comparison 📏

SDK	Before	After	Difference	Status
stream-video-android-core	12.27 MB	12.27 MB	0.00 MB	🟢
stream-video-android-ui-xml	5.68 MB	5.68 MB	0.00 MB	🟢
stream-video-android-ui-compose	6.20 MB	6.20 MB	0.00 MB	🟢

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rahul-lohra]

lgtm

[stream-public-bot]

🚀 Available in v1.30.0