[SCH-531]Implement polling fallback for waiting room if websocket fails

[ivanjiang5628]

Description

• Linear Ticket SCH-531

• Linear Ticket SCH-542

• Previously in the waiting room when socket connection fails, video chat app would bypass the waiting room to navigate the user to the session directly. After discussions with Brian and Trev, In this socket failure scenario, we believe that using polling should be a more reliable solution than navigating users to the session directly.

In this PR:

• When "_connectionStatusListener" receives an socket error it auto fallbacks to polling to retrieve the latest waiting room states via "checkRoomStatus" API request every 5 seconds.
• If any error occurs while polling, video chat app will stop polling after three retries and pop up an error notification. then redirect the user to the welcome page after a 5 seconds delay.
• the socketConnection component will send the latest polling response to iOS app .
• Stop displaying waiting room error notification to prevent confusion.
• Clear up & refractor the socket class for the polling fallback.
• the PR would also fix SCH-542

General PR Class

👁 = UX / UI improvement

Release Note

Dependencies / ENV

Risk Scorecard

1. As the author you should check the boxes that correspond with your PR and then use the following guide to set your risk label:

• 0 checkboxes => low risk
• 1-3 checkboxes => medium risk
• 4+ checkboxes => high risk

2. Unless exempt, checked risk factors should be explained comprehensively in the Release Risk Assessment section below
3. Medium or higher risk PRs should get more than one code-review approval

NOTE: if you aren't changing any production files, please use the zero risk label

• requires env configuration to be added in production
• js package changes¹
• more than 200 LOC changed in production files¹
• includes a user-facing workflow change to an existing production feature (user muscle memory or pattern recognition will be affected)
• could prevent access to Jane Video (eg. cors, middleware, changes to auth system)
• affects a widely used component or piece of code
• I have a doubt - I want the RMT to review this. If possible, please elaborate your concerns in the risk assessment section.

¹ No need to explain these risk factors below

Release Risk Assessment

Medium since it could prevent access to the video session from waiting room.

Demo Notes

Code Review

Resource: Dev Team Notion Page
Resource: Code Review Checklist

• I clearly explained the WHY behind the work, in the Description above

Design

• I added instructions for how to test, in the QA section below
• I added specs for changes, or determined that none were required
• I demoed this to the appropriate person
• I considered both mobile & desktop views, or that wasn't relevant

Code

• I committed code with informative git messages
• I wrote readable code, or added comments if it was complex
• I performed a self-review of my own code
• I rebased my branch on the latest master

QA and Smoke Testing

Steps to Reproduce

1. Please deploy SCH-531-test-branch to s8 sandbox (This build will pass an incorrect socket token to jitsi and make jitsi's websocket connection unavailable）
   

2. Create an online appointment on s8

3. Open a jitsi web app or iOS app (the functionality should work on both desktop & mobile devices)

4. When socket fails can see an "Unable to connect socket.io" error in the browser console
   

5. Jitsi would auto fallback to polling to retrieve the latest room states

6. The waiting room should work as usual

we could open the network tab in chrome dev tools to monitor the polling request sent every 5 seconds.

We also need to switch back to a build(i.e., sch-1006) that doesn't break the socket connection in S8 and smoke test the waiting room to ensure the socket connection works properly.

Fixed / Expected Behaviour

Jane Desktop

• Should these changes be tested in Jane Desktop? If the PR touches any of the areas outlined here, the answer is probably yes. If yes, indicate which areas.
• How to test video-chat inside Jane Desktop locally is outlined here

Other Considerations

• Will this affect other parts of the app or views?
• How can the success of this work be confirmed after release to production?
• What QA have you already done?

Screenshots

Before

After

[linear]

SCH-531 Implement polling fallback for waiting room if websocket fails

Previously in the waiting room if the socket connection failed, the video chat app would bypass the waiting room to redirect the user to the session directly. After discussions with Brian and Trev, In this socket failure scenario, polling should be a more reliable solution than navigating users to join the session directly.

[JuliaMoniqueRix]

Demo / Pre QA Testing

Error message achieved!

[linear]

SCH-542 Jitsi web app keeps reloading the page automatically if the session jwt token expires.

[ivanjiang5628]

Stop displaying this error notification due to a user complaint

[hollandmatt]

Looks good!

[CasTodesco]

Before Testing

• CI must be passing
• No conflicts
• No unresolved reviews/changes requested
• No additional changes/pushes from dev since the last round of QA
• NA Release note is sufficient for #features
• Read through Notion / Linear Issue / Slack Convo / Demo video
• Read through comments

Developer's Recommended Test Plan

• Please deploy SCH-531-test-branch to s8 sandbox (This build will pass an incorrect socket token to jitsi and make jitsi's websocket connection unavailable）
• Create an online appointment on s8
• Open a jitsi web app or iOS app (the functionality should work on both desktop & mobile devices)
• When socket fails can see an "Unable to connect socket.io" error in the browser console
  
• Jitsi would auto fallback to polling to retrieve the latest room states
• The waiting room should work as usual
• we could open the network tab in chrome dev tools to monitor the polling request sent every 5 seconds.
• We also need to switch back to a build(i.e., sch-1006) that doesn't break the socket connection in S8 and smoke test the waiting room to ensure the socket connection works properly.

Additional Thoughts on Testing

Mobile, Browsers, Jane Desktop

• chrome
• iOS mobile
• firefox
• safari
• opera
• android

Regression Testing / Exploratory

Peer Review for Moderate Risk or Higher

• Peer Review

Pass Story on QA Board / Mark Scheduled for Release in Linear

• LGTM

For new features and improvements to UX: Add test cases to Steve Hong's Notion Document

• Steve has my test cases

Labels

• Portfolio Team label is added
• T-shirt label is added

Move PR on Roll Out Board

• Moved from QA to Patch Release Candidate