[Due for payment 2026-01-27] Infinite loading when open secondary login chat page

[mitarachim]

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: v9.3.3-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-2989/folder/13176682/41236552/1128448348?sort=-status_id
Email or phone of affected tester (no customers): gocemate+b215490630@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Chat Report View

Action Performed:

Precondition:

1. Prepare an account that has a secondary login assigned
2. Log in with another account and start a conversation with the primary login of the account from step 1
3. Send some messages in the conversation

Steps

1. Log in with the account that has the conversation with the user that has 2 logins
2. Click on FAB> New Chat> Enter secondary login

Expected Result:

User should redirect to the conversation with the primary login email

Actual Result:

Infinite loading when open secondary login chat

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7050390_1768502647111.Recording__113.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (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 @marcaaron (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #79410 - "[Part 2]Remove Onyx.connect() for the key: ONYXKEYS.SESSION in src/libs/actions/Report.ts" by @linhvovan29546 (High confidence)
Related Issues: None found

Recommendation: REVERT

Reverting #79410 is the safest approach as it modified core report navigation logic and this bug affects a critical user flow (starting chats with secondary logins).

Labels: Keeping DeployBlockerCash (App deploy blocked). This issue does not require backend changes.

Detailed Analysis

Evidence

PR #79410 was merged on 2026-01-14 at 15:28:05 UTC, which aligns with when this bug appeared on staging (v9.3.3-0).

The PR modified navigateToAndOpenReportWithAccountIDs and other functions in src/libs/actions/Report.ts as part of removing the deprecated deprecatedCurrentUserAccountID variable. While the changes appear correct at first glance, they exposed a pre-existing bug in how secondary logins are handled.

Verification

Affected files:

• /home/runner/work/App/App/src/libs/PersonalDetailsUtils.ts - getAccountIDsByLogins() function (lines 154-165)
• /home/runner/work/App/App/src/libs/actions/Report.ts - navigateToAndOpenReport() function (lines 1398-1448)
• /home/runner/work/App/App/src/pages/NewChatPage.tsx - Line 391 where navigateToAndOpenReport([login]) is called

The PR modified Report.ts, which directly affects the chat navigation flow.

Root Cause

When a user tries to open a chat with a secondary login email:

1. NewChatPage calls navigateToAndOpenReport([secondaryLogin])
2. Inside that function, PersonalDetailsUtils.getAccountIDsByLogins(userLogins) is called
3. The bug: getAccountIDsByLogins searches personal details using detail?.login === login?.toLowerCase(), but personal details only store the primary login, not secondary logins
4. When the secondary login isn't found, it generates a new/fake account ID using generateAccountID(login)
5. getChatByParticipants is called with this incorrect account ID
6. It fails to find the existing chat (which uses the primary account ID)
7. An optimistic report is created with wrong participant IDs
8. openReport is called and gets stuck in infinite loading

Why PR #79410 Triggered This

While the underlying issue (secondary logins not being matched properly) existed before, PR #79410's refactoring of the session/account ID handling likely changed the timing or flow in a way that makes this bug consistently reproducible. The PR removed deprecatedCurrentUserAccountID in favor of passing currentUserAccountID explicitly, which may have altered how the account matching works.