[Due for payment 2026-05-22] [$250] DM with assigned account manager appears grayed out on Inbox page

[MelvinBot]

Bug Description

The DM thread with an assigned account manager appears grayed out in the Inbox page, preventing the admin from initiating contact.

Related feature: #85990

Steps to Reproduce

1. Log into the workspace as an admin.
2. Navigate to the Inbox page.
3. Locate the assigned account manager contact/DM thread.
4. Attempt to open or message the account manager.
5. Observe that the DM option is grayed out and inaccessible.

Chat Link: https://www.expensify.com/concierge/#/chat/24200231

Expected Result

The admin should be able to open the DM thread and send messages to the assigned account manager from the Inbox page.

Actual Result

The DM with the account manager is grayed out, preventing the admin from contacting them.

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053847630458819214
• Upwork Job ID: 2053847630458819214
• Last Price Increase: 2026-05-11

[MelvinBot]

Proposal

What is the root cause of that problem?

When the account manager DM is opened from the HelpPage, navigateToAndOpenReportWithAccountIDs is called. If no existing chat is found locally in Onyx (via getChatByParticipants), a new optimistic report is created with pendingFields.createChat = 'add'.

Each LHN row is wrapped by OfflineWithFeedback, which applies 50% opacity when:

1. The user is offline and a pendingAction exists, or
2. The pendingAction is 'add' and the report has errors

The pendingAction on LHN rows is sourced from report.pendingFields.createChat.

The problem is that openReport's failureData does not clear pendingFields.createChat on failure. If the API call fails (or the user is offline when the DM is created), pendingFields.createChat stays as 'add', and the report accumulates errorFields — triggering the isAddError condition in OfflineWithFeedback, which permanently grays out the row.

Additionally, even when the server already has this DM (via accountManagerReportID), the client may not have it cached locally. getChatByParticipants returns null, causing navigateToAndOpenReportWithAccountIDs to create a duplicate optimistic report instead of reusing the existing server-side one.

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

Add failureData in openReport (around line 1549) to clear pendingFields.createChat and set errorFields.createChat when the new-report creation block (isCreatingNewReport) is entered. This ensures the grayed-out state is resolved on failure — the error indicator can still show via errorFields, but the opacity won't persist indefinitely.

Something like adding to the isCreatingNewReport block:

failureData.push({
    key: report collection key,
    value: {
        pendingFields: { createChat: null },
        errorFields: { createChat: <error with translation key> },
    },
});

Additionally, the HelpPage path should prefer navigating to accountManagerReportID (already available in Onyx via the Account key) rather than using navigateToAndOpenReportWithAccountIDs which risks creating a duplicate optimistic report. The AccountManagerBanner already does this correctly — it navigates directly to the known accountManagerReportID.

What alternative solutions did you explore?

An alternative is to only fix the HelpPage navigation to use accountManagerReportID directly (matching AccountManagerBanner's approach), which would avoid the optimistic report creation entirely for this specific case. However, fixing the missing failureData in openReport is a more robust fix since the same bug could affect any new DM creation that fails, not just the account manager case.

---

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.