[Due for payment 2026-04-16] [$250] Chat - Page not Found message appears after Replying to thread offline & simulating error

[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.34-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84479
Email or phone of affected tester (no customers): applausetester+en@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Macbook Pro 2023 / Sequoia 15.2
App Component: Chat Report View

Action Performed:

1. Open staging,new.expensify.com
2. Disable network
3. Create message
   4, Reply in thread
4. Enable Simulate failing network requests ( I used CMD + D on MAC)
5. Go online
6. Observe that the error message will be shown
7. Click X button on the parent message

Expected Result:

Verify that we'll redirect to Concierge chat

Actual Result:

User is redirected to page not found message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022031256611079526733
• Upwork Job ID: 2031256611079526733
• Last Price Increase: 2026-03-10
• Automatic offers:
• thelullabyy | Contributor | 110792100

[melvin-bot]

Triggered auto assignment to @mallenexpensify (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.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user goes offline, sends a message, replies in thread, enables "Simulate failing network requests", and goes back online, clicking the X button on the failed parent message causes a "Page not found" screen instead of redirecting to the Concierge chat.

What is the root cause of that problem?

The issue is in ReportActionItemParentAction.tsx — specifically in how the error dismissal on ancestor reports navigates the user.

When a message fails to send and the user is viewing the thread, there are two OfflineWithFeedback wrappers:

1. Outer wrapper (line 168-174): Handles the thread report's own createChatThread error. Its onClose calls navigateToConciergeChatAndDeleteReport(report?.reportID, ..., undefined, true) — this deletes the thread and navigates to Concierge.

2. Inner wrapper (line 193-199): Handles each ancestor report's createChat error. Its onClose calls navigateToConciergeChatAndDeleteReport(ancestorReport.reportID, ..., introSelected) — this deletes the parent report only (shouldDeleteChildReports=false), leaving the thread orphaned in Onyx.

The core problem is in navigateToConciergeChatAndDeleteReport (Report/index.ts:3780-3799): it calls Navigation.goBack() followed by navigateToConciergeChat(..., false). When called from inside a thread:

• goBack() pops the thread view, briefly showing the parent report
• navigateToConciergeChat with shouldDismissModal=false uses Navigation.navigate() which may not properly replace the current screen depending on navigator state
• deleteReport then runs after interactions and removes the parent report from Onyx
• If the navigation to Concierge didn't fully settle, the user is left viewing the now-deleted parent report route → "Page not found"

Additionally, when the parent action's error is dismissed directly through clearReportActionErrors (via the ReportActionItem's own OfflineWithFeedback), the optimistic parent action is removed from Onyx but no navigation occurs at all — unlike deleteReportComment which has explicit navigation handling at lines 2549-2553 for when the user is viewing a child thread. The thread remains displayed with a missing parent action, and its createChatThread error may not properly redirect.

Note: While this bug was discovered during QA of PR #84479, the PR only inserted an introSelected parameter into navigateToConciergeChatAndDeleteReport calls — the navigation and deletion logic is identical before and after. This bug is pre-existing.

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

The fix should be in ReportActionItemParentAction.tsx — change the outer OfflineWithFeedback's onClose handler (line 174) to pass shouldPopToTop=true instead of undefined:

navigateToConciergeChatAndDeleteReport(report?.reportID, conciergeReportID, currentUserAccountID, introSelected, true, true)

Using popToSidebar() instead of goBack() ensures the navigation stack is fully reset before navigating to Concierge, preventing the race condition where goBack() lands on an intermediate screen that gets deleted.

Similarly, the inner OfflineWithFeedback's onClose handler (line 199) should also pass shouldPopToTop=true and shouldDeleteChildReports=true so the thread is properly cleaned up when the parent report is deleted:

navigateToConciergeChatAndDeleteReport(ancestorReport.reportID, conciergeReportID, currentUserAccountID, introSelected, true, true)

What alternative solutions did you explore? (Optional)

An alternative would be to add navigation logic to clearReportActionErrors (similar to what deleteReportComment has at lines 2549-2553) to navigate the user away from the thread when the parent action is removed. However, this is more invasive and clearReportActionErrors is a shared utility used in many contexts. The popToSidebar approach is simpler and more targeted.

---

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 - @ShridharGoel (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022031256611079526733

[raju-h]

Contributor details
Expensify account email: rajuhosseng@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01c9f56cebd089cf23

[raju-h]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user goes offline, sends a message, replies in a thread, then enables "Simulate failing network requests" and goes back online, clicking the X button on the error indicator for the parent message shows a "Page not found" screen instead of navigating to Concierge chat.

What is the root cause of that problem?

The root cause is in navigateToConciergeChatAndDeleteReport in src/libs/actions/Report/index.ts. This function performs a two-step navigation: first it calls goBack() to pop one screen from the stack, then it calls navigateToConciergeChat() to push Concierge chat on top.

When the user is viewing a thread and dismisses the createChatThread error (via the outer OfflineWithFeedback in ReportActionItemParentAction.tsx, line 174), goBack() pops the thread view and lands on the parent report screen. However, the parent report was also created during the offline session and is in a failed/broken state. The user briefly lands on this invalid intermediate screen, and ReportScreen evaluates shouldShowNotFoundPage as true, rendering "Page not found" before Concierge navigation can complete.

The outer OfflineWithFeedback passes shouldPopToTop=undefined (defaults to false) and shouldDeleteChildReports=true. Since shouldPopToTop is false, goBack() is used instead of popToSidebar(), causing the intermediate screen problem.

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

In navigateToConciergeChatAndDeleteReport, instead of the two-step goBack()/popToSidebar() followed by navigateToConciergeChat(), call navigateToConciergeChat() with shouldDismissModal=true. This uses Navigation.dismissModalWithReport() which atomically replaces the current screen with Concierge chat. No intermediate screen is ever rendered.

The goBack()/popToSidebar() call and the shouldPopToTop parameter can be removed entirely from the function, simplifying the logic. The deleteReport() call via InteractionManager.runAfterInteractions remains unchanged.

This eliminates the race condition at its source and fixes both the outer and inner OfflineWithFeedback wrappers without needing to change any call sites.

What alternative solutions did you explore? (Optional)

1. Changing line 174 in ReportActionItemParentAction.tsx to pass shouldPopToTop=true — this works for this specific call site but still relies on the two-step navigation pattern which is inherently racy, and doesn't protect other callers.

2. Making popToSidebar() automatic when shouldDeleteChildReports=true inside navigateToConciergeChatAndDeleteReport — more robust than option 1 but still uses two navigation steps. The dismissModalWithReport approach is cleaner because it removes the intermediate state entirely.