Stop waiting on a verification request the other session never accepts

[hayaksi1]

Content

The outgoing verification flow has no client-side timeout. Once a request is sent the screen sits on "Waiting to accept request" indefinitely: if the other session never answers, or is not running at all, nothing in the app ever tells the user the request can no longer succeed, and the only way out is to press back.

Bound that wait to ten minutes, the lifetime the Matrix specification gives a m.key.verification.request. Past that point the other session can no longer accept it, so waiting longer cannot succeed. On expiry the request is cancelled and the machine moves to its existing canceled state, which already offers to start again.

The duration is anchored to the specification rather than chosen for UX reasons: cancelling earlier would abort verifications that would still have completed once the user picked up their other device.

Motivation and context

Part of #1270.

Tests

features/verifysession/impl/.../OutgoingVerificationPresenterTest.kt: a new case asserts that a request nobody accepts stays in the waiting state at nine minutes, then cancels the verification and moves to the canceled state once the timeout passes.

The shared helper that drives a verification to the verifying state now advances time by a bounded amount instead of advanceUntilIdle(), which would otherwise skip straight past the new timeout.

Run with ./gradlew :features:verifysession:impl:testDebugUnitTest.

Tested devices

• Physical
• Emulator
• OS version(s):

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot.
  • No.
• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.

[bmarty]

Tested OK, thanks!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.62%. Comparing base (8b2c207) to head (ad502c0).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7457      +/-   ##
===========================================
- Coverage    80.64%   80.62%   -0.02%     
===========================================
  Files         2758     2758              
  Lines        80588    80593       +5     
  Branches     11029    11029              
===========================================
- Hits         64989    64979      -10     
- Misses       11342    11360      +18     
+ Partials      4257     4254       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bmarty]

It seems that there is an unused import:

/home/runner/work/element-x-android/element-x-android/features/verifysession/impl/src/test/kotlin/io/element/android/features/verifysession/impl/outgoing/OutgoingVerificationPresenterTest.kt:30:1: The import 'kotlinx.coroutines.test.TestScope' is unused. [UnusedImports]

[hayaksi1]

@bmarty Done — restored the file-level @file:Suppress("UnusedImports") this branch had dropped. The import is genuinely needed: TestScope only appears in the context(testScope: TestScope) parameter of requestVerificationAndAwaitVerifyingState, which the ktlint rule does not look at, so the suppression was there for exactly this reason and removing it was an accident on my side.

:features:verifysession:impl:ktlintCheck, detekt and testDebugUnitTest are green locally.