[$250] Chat - Unexpected error after created a room then send message to new user via share code

[jponikarchuk]

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.40-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
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-10402/folder/13176964/41237748/1260627404
Email or phone of affected tester (no customers): lekima20+663002@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Win 11/Chrome
App Component: Chat Report View

Action Performed:

Precondition: On other browser login with account never chat with user at main browser, at Profile copy the Share code ulr

1. Open https://staging.new.expensify.com login as owner of a workspace
2. Click on Start chat and create a room
3. Navigate to any other conversation
4. Paste and send the copied Share code ulr of user never chat with
5. Click on the link
6. Click on Message
7. Type and send a message

Expected Result:

The message is sent successfully

Actual Result:

"Unexpected error posting the comment. Please try again later" is displayed after sent message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @brunovjk

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043742113514932110
• Upwork Job ID: 2043742113514932110
• Last Price Increase: 2026-04-13

[MelvinBot]

Proposal

What is the root cause of that problem?

There is a bug in the navigateToReport function at src/libs/actions/Report/index.ts:1970-1972 that causes double navigation to the same report screen.

When clicking "Message" on a profile opened via share code, navigateToAndOpenReport is called with shouldDismissModal=false (PromotedActionsBar.tsx:84). Inside navigateToReport, this triggers:

1. An immediate Navigation.navigate(...) on line 1967 (the else if branch)
2. A second Navigation.navigate(...) inside a setTimeout on lines 1970-1972 that always runs regardless of the shouldDismissModal flag

The setTimeout block was added as a workaround for composer focus issues when dismissing RHP modals, but it unconditionally executes for all callers. This causes the ReportScreen to navigate/re-render twice in quick succession.

The critical interaction: after creating a workspace room (step 2 in repro), AddWorkspaceRoom is queued in the sequential queue. When the user then creates a new DM via share code, OpenReport is queued next, and AddComment after that. The double navigation can cause ReportFetchHandler (ReportFetchHandler.tsx:102-105) to fire a second openReport call if the first OpenReport completes between the two navigations (flipping isOptimisticReport from true to false). This duplicate OpenReport via resolveOpenReportDuplicationConflictAction replaces the original in the queue, potentially disrupting the ordering guarantee that AddComment depends on — causing the server to receive AddComment for a report that isn't fully set up.

What changes do you think we should make in order to solve the problem?

The setTimeout navigation block in navigateToReport (lines 1970-1972) should only execute when shouldDismissModal is true, which is the case it was designed for. Wrap it in the shouldDismissModal condition:

function navigateToReport(reportID, shouldDismissModal = true) {
    if (shouldDismissModal) {
        Navigation.dismissModal({
            callback: () => {
                if (!reportID) { return; }
                Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
            },
        });
        // Workaround: when RHP modal gets hidden, composer focus breaks — delayed navigation fixes this
        setTimeout(() => {
            Navigation.isNavigationReady().then(() => Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID)));
        }, 0);
    } else if (reportID) {
        Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
    }
}

This eliminates the double navigation for the share code → DM flow while preserving the existing composer-focus workaround for the modal-dismiss path.

What alternative solutions did you explore? (Optional)

An alternative would be adding a guard in ReportFetchHandler to debounce or skip duplicate openReport calls for the same reportID within a short window. However, fixing the root cause in navigateToReport is simpler and avoids the double navigation entirely.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @brunovjk (External)