Skip to content

Stop waiting for a room alias that the remote server never resolves - #7446

Open
hayaksi1 wants to merge 1 commit into
element-hq:developfrom
hayaksi1:fix/5267-room-alias-resolver-timeout
Open

Stop waiting for a room alias that the remote server never resolves#7446
hayaksi1 wants to merge 1 commit into
element-hq:developfrom
hayaksi1:fix/5267-room-alias-resolver-timeout

Conversation

@hayaksi1

Copy link
Copy Markdown
Contributor

Content

Tapping a room alias whose homeserver is unreachable left the resolver screen on a spinner for as long as the screen stayed open. resolveRoomAlias was awaited with no bound, so a federation request that never comes back never produced a state the screen could render, and the only way out was to press back.

The resolution is now bounded by the same ten second timeout that resolving an address already uses when joining a room by address, and a timeout surfaces as a failure. The screen then shows its retry dialog rather than spinning.

The alias is still not resolved locally for a room the user has already joined, which is what the reporter suggested; that needs a way to look a room up by alias that the client does not expose today.

Motivation and context

Part of #5267.

Tests

  • features/roomaliasresolver/impl/.../RoomAliasHelperPresenterTest.kt: a client whose resolution never completes ends in a failure state instead of staying loading.
  • FakeMatrixClient's resolve lambda becomes suspending so a server that never answers can be simulated; existing callers are unchanged.

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

Tapping a room alias whose server is down left the resolver screen on a
spinner for as long as the screen stayed open, with no way forward other
than going back.

Bound the resolution with the ten second timeout already used when
joining a room by address, so the retry dialog is shown instead. The fake
client's resolve lambda becomes suspending so a server that never answers
can be simulated.
@hayaksi1
hayaksi1 requested a review from a team as a code owner August 17, 2026 01:06
@hayaksi1
hayaksi1 requested review from jmartinesp and removed request for a team August 17, 2026 01:06
@github-actions

Copy link
Copy Markdown
Contributor

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.

@github-actions github-actions Bot added the Z-Community-PR Issue is solved by a community member's PR label Aug 17, 2026
@codecov

codecov Bot commented Aug 19, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.64%. Comparing base (23b75c3) to head (c95b7e3).
⚠️ Report is 39 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #7446      +/-   ##
===========================================
- Coverage    80.65%   80.64%   -0.02%     
===========================================
  Files         2772     2772              
  Lines        80803    80806       +3     
  Branches     11053    11054       +1     
===========================================
- Hits         65168    65162       -6     
- Misses       11370    11381      +11     
+ Partials      4265     4263       -2     

☔ 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.

@jmartinesp jmartinesp added the PR-Bugfix For bug fix label Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR-Bugfix For bug fix Z-Community-PR Issue is solved by a community member's PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants