fix(call): recover from stale room session instead of ringing forever - #6550
fix(call): recover from stale room session instead of ringing forever#6550tareko wants to merge 2 commits into
Conversation
Rejoining a call after a network drop reuses the cached room session from ApplicationWideCurrentRoomHolder. If the server reaped that session in the meantime (sessions that stop pinging are invalidated), the signaling server rejects the join with "no_such_room". That error was only logged, and the calling timeout is armed only after a successful join, so the call UI showed "Ringing" forever with no way out. - WebSocketInstance: handle "no_such_room" by clearing the cached room join state (so a retry actually sends) and posting a roomJoinFailed event - CallActivity: on roomJoinFailed, drop the cached session and re-run the joinRoom API to fetch a fresh one, retrying the join; after two failed refreshes, show an error and leave instead of ringing forever; never touch an already established call Assisted-by: opencode:ox-alpha Signed-off-by: Tarek Loubani <tarek@tarek.org>
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/32633346061/artifacts/9491721238 |
There was a problem hiding this comment.
Pull request overview
This PR addresses a call rejoin failure mode where a stale cached room session can cause the UI to remain stuck on “Ringing” indefinitely by detecting the no_such_room join rejection, clearing cached join state, and retrying join with a refreshed room session a bounded number of times.
Changes:
- Treat
no_such_roomas a stale-room-session signal in the external signaling WebSocket flow and notify the UI layer. - Add bounded room-session refresh + rejoin retry logic to
CallActivity, with a user-visible failure and exit after the retry limit. - Add a unit test covering the refresh decision logic (
shouldRefreshRoomSession) and a new user-facing error string.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| app/src/main/java/com/nextcloud/talk/webrtc/WebSocketInstance.kt | Clears cached join state on no_such_room and emits a join-failure event for the UI to react to. |
| app/src/main/java/com/nextcloud/talk/activities/CallActivity.kt | Implements bounded session refresh + join retry on roomJoinFailed, and surfaces failure to the user. |
| app/src/main/res/values/strings.xml | Adds a localized string for “could not join call” failure feedback. |
| app/src/test/java/com/nextcloud/talk/activities/CallActivityRoomJoinRefreshTest.kt | Adds unit tests to validate the refresh gating/limits logic. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
CallActivity.onMessageEvent only processes WebSocketCommunicationEvents whose HashMap is non-null, so the roomJoinFailed event posted with null was silently dropped and the room session refresh never ran. Assisted-by: opencode:ox-alpha Signed-off-by: Tarek Loubani <tarek@tarek.org>
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/32661925390/artifacts/9499069983 |
fix(call): recover from stale room session instead of ringing forever
Description
Rejoining a call reuses the cached room session from
ApplicationWideCurrentRoomHolderwhenever it is non-empty — it is never validated. If the server reaped that session in the meantime (spreed invalidates sessions that stop pinging,session-ping-limit), the signaling server rejects the join withno_such_room("The user is not invited to this room"). That error was only logged (processErrorMessagehandled justno_such_session/hello_expected), and the calling timeout is armed only after a successful join — so the call UI showed "Ringing" forever with no way out. Reproduced live after a WiFi drop: reconnecting to the call was impossible until the app was restarted.Changes:
WebSocketInstance:no_such_roomnow clears the cached room join state (so a retry actually sends a new join message) and posts aroomJoinFailedeventCallActivity: onroomJoinFailedthe cached session is dropped and the joinRoom API is re-run to fetch a fresh session, then the join is retried. After two failed refreshes the user gets an error and the call screen closes instead of ringing forever. An already established call is never disturbed by a stray error.How to test
Without this PR: infinite "Ringing".
With this PR: the app fetches a fresh session and joins; if joining genuinely fails (e.g. removed from the conversation), an error toast is shown and the call screen closes.
Also regression-test: normal call joins, joining from a notification, and rejoining after a network switch.
CallActivityRoomJoinRefreshTest)Note: This PR was developed with AI assistance (opencode / Kimi-K3); see the
Assisted-bycommit trailer. Verified on a physical device (Samsung SM-S938B) against a live HPB+Janus setup.