App crashes when attempting to open an #admins room

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.0.3-1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @francoisl
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1719528213578329

Action Performed:

1. Create a workspace
2. Open the workspace's settings page and change anything that would cause a system message in the admins room
   For example, create, delete, rename or disable a category ; add tags, etc.
3. Try to open the admins room for that workspace

Expected Result:

Workspace Admin room opens

Actual Result:

App crashes when opening admin room

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Screen.Recording.2024-06-27.at.3.41.34.PM.mov

Recording.263.mp4

Recording.262.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @CortneyOfstad (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @robertjchen (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[neonbhai]

Fixed on latest main:

Screen.20Recording.202024-06-28.20at.205.mp4

[robertjchen]

got it, thanks!

[mountiny]

@neonbhai Sorry to confirm, you mentioned its fixed on main, but is it fixed on staging?

[neonbhai]

@mountiny hi, cannot reproduce on staging:

Screen.Recording.2024-06-28.at.2.30.36.PM.mov

[m-natarajan]

@mountiny we are still able to reproduce this bug and clicking on the WS right after creating the WS also crashes the app.

Recording.265.mp4

[mountiny]

@neonbhai can you try in offline? maybe its issue with optimistic data

[neonbhai]

I can reproduce the crash when creating a workspace -> changing name -> switching to it from workspace switcher:

Screen.Recording.2024-06-28.at.5.01.28.PM.mov

The console error is for maximum update depth exceeded. Ref link

Crash doesn't reproduce for me for the system message steps (both online and offline):

Attempt 1 (offline)

Screen.Recording.2024-06-28.at.5.05.38.PM.mov

Aside: We don't set an optimistic system message for toggling of category/tags

Attempt 2 (online)

Screen.Recording.2024-06-28.at.5.05.38.PM.mov

cc: @mountiny

[robertjchen]

Was this a regression from a recent change? 👀

[jasperhuangg]

@neonbhai Does the stack trace indicate which component is exceeding the max update depth?

[neonbhai]

Looks like its coming from the ReportScreen component:
​

[jasperhuangg]

At first glance this seems suspicious: #44412

[jasperhuangg]

#44412 is not the cause :/

[jasperhuangg]

The issue has either something to do with:

• the optimistic data set when we call UpdateWorkspaceGeneralSettings
• Something about how the workspace switcher works
• Something about how the ReportScreen works

[jasperhuangg]

I can't seem to reproduce this on desktop

[jasperhuangg]

I think this is the cause #44559

Namely the code that calls getSnapshot here cc @roryabraham

Need to set USE_REACT_STRICT_MODE flag to false in CONFIG.ts. Can reproduce this consistently with my account on staging with the following steps:

1. Sign into any account
2. Create a new workspace.
3. Rename that workspace.
4. In the workspace list, click the three dots and click "Go to #admins room".

[robertjchen]

@jasperhuangg Awesome investigation! 🙇

[jasperhuangg]

@robertjchen @roryabraham Still looking into this, it's either caused by #44412 or #44559, or a combination of the two 😆 I'm trying every possible combination now.

[jasperhuangg]

Okay yep confirmed it's caused by #44412, reverting that fixes things for me locally

[jasperhuangg]

Looks like @roryabraham is OOO today so in the interest of pushing deploy forward I'm gonna go ahead and revert that PR

[jasperhuangg]

btw @roryabraham here's the error

[roryabraham]

Reverting that PR will cause another regression @jasperhuangg

edit: sorry, was thinking of another PR. This one should be fine to revert

[roryabraham]

@jasperhuangg can you try this PR and see if it solves the problem?

#44681

[roryabraham]

If it does, you could actually take it a step further and just remove the useLastAccessedReportID hook and put findLastAccessedReport in a useEffect directly

[neonbhai]

Came across very similar warning to #44583 (comment) while investigating this on native device, asking to memoize getSnapshot call in useOnyx.ts

Image

[jasperhuangg]

Ah shoot @roryabraham jumped the gun and missed your messages, my bad! The CP is already under way and it looks like that PR you linked is still an early draft–do you mind if we try to get it out in tomorrow's deploy? I'd feel better if we had some more time to test everything thoroughly without any time pressure today.

[jasperhuangg]

Can't reproduce this anymore on staging