fix: re-subscribe rooms stream after forced socket reopen#7362
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📜 Recent review details⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
WalkthroughThe PR calls ChangesStream Close Unsubscribe Rooms Guard Reset
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested labels
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (1)
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 |
|
Android Build Available Rocket.Chat 4.73.0.108999 Internal App Sharing: https://play.google.com/apps/test/RQQ8k09hlnQ/ahAO29uNSzEZLV48QqMLm01fO63uOynryyNiHxSqus-xRmI9xiF90aqh3JWOzuKZ_cCOI-x38Z8tkEGnT-xDQ7OYOc |
|
iOS Build Available Rocket.Chat 4.73.0.109000 |
A long background marks the DDP socket stale, so foregrounding triggers checkAndReopen -> forceReopen, which drops all SDK subscriptions and reopens the socket without going through connect(). The module-level roomsSubscription guard therefore stayed set, so subscribeRooms() skipped re-subscribing stream-notify-user and the rooms list silently stopped reflecting subscriptions/favorites/reads until a manual reconnect. Reset the guard from the socket 'close' listener (via unsubscribeRooms), the same teardown connect() already performs, so the resume-login that follows the reopen re-subscribes stream-notify-user. Other streams (permissions, presence, settings, roles) subscribe unconditionally and were never affected.
19944a4 to
6dd8818
Compare
Brings the 4.73.1 release into the single-server line. Conflict resolution (mirrors the 4.73.0 single-server merge, NATIVE-1205): - Version files (package.json, build.gradle, Info.plist x2, pbxproj) -> 4.73.1 - android/gradle.properties -> single-server values (APPLICATION_ID=chat.rocket.reactnative, VERSIONCODE=1, keystore block) - Firebase configs kept deleted (google-services.json, GoogleService-Info.plist, debug strings.xml) - connect.ts / connect.test.ts -> 4.73.1 (single-server merely lacked the unsubscribeRooms() close-listener fix RocketChat#7362) - pnpm-lock.yaml / Podfile.lock -> 4.73.1 (only delta was picker 2.11.1 -> 2.11.4) - Single-server product customizations intact (app.json hardcoded server, disabled NewServerView, disabled ServersList switcher)
Proposed changes
After the app sits in the background for a while the DDP socket goes stale, so foregrounding triggers
checkAndReopen→forceReopen.forceReopendrops every SDK subscription and reopens the socket without going throughconnect(), so the module-levelroomsSubscriptionguard insubscribeRoomsstays set. The nextsubscribeRooms()therefore short-circuits and never re-subscribesstream-notify-user, and the rooms list silently stops reflecting subscription/favorite/read changes until a manual reconnect or app restart.This resets that guard from the socket
'close'listener (viaunsubscribeRooms()) — the same teardownconnect()already performs at startup — so the resume-login that follows the reopen re-subscribesstream-notify-user.stream-notify-useris the only stream behind that guard; the other streams (permissions, presence, settings, roles) callsdk.subscribe(...)unconditionally and were never affected.Issue(s)
https://rocketchat.atlassian.net/browse/SUP-1047
How to test or reproduce
subscriptions-changedevent — e.g. favorite/unfavorite a room or mark one read.Verified on an Android 16 emulator: after foregrounding,
subscribeRooms()re-subscribesstream-notify-userand a favorite toggle then fires the handler and the WatermelonDB write. A regression test inconnect.test.tsasserts the'close'listener callsunsubscribeRooms()(and fails if the call is removed).Types of changes
Checklist
Further comments
The fix lives in the
'close'listener rather than insubscribeRoomsitself because'close'is already the place app state is reset for reconnect (it dispatchesdisconnectAction()to flip Reduxmeteor.connected→ false). The SDK'sforceReopendocuments this contract: it emits'close'soconnect.tsflips that state, otherwise the next'connected'short-circuits and the loginRequest → subscribeNotifyUser chain never re-runs. TheroomsSubscriptionguard is just a second piece of "am I subscribed?" state that has to be reset in that same spot.Summary by CodeRabbit
Bug Fixes
Tests