[$250] Chat - Email for new expenpensifail account conversations in account details not shown

[applause-bot]

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.98-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-37766/folder/13176683/41236571/1459449130?sort=%2Bidentifier
Email or phone of affected tester (no customers): N/a
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11/ Chrome
App Component: Chat Report View

Action Performed:

1. Sign in staging.new.expensify.com
2. Click on FAB > Start chat
3. Enter an expensifail account address (eg. applausetester+testemail@applause.expensifail.com)
4. Open the conversation
5. Click on the account header

Expected Result:

The login detail displays "Email" and the email

Actual Result:

Chat detail RHP displays hidden and no email is displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7170765_1780512107898.bandicam_2026-06-03_21-27-50-495.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7170765

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072794921257720093
• Upwork Job ID: 2072794921257720093
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @mukhrr

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/cf9830d31cbed157029bec879106e85f63a6f432541d1e7fc64000384cc38fbd

[MelvinBot]

Issue Analysis

Root cause: The profile RHP renders the email from personalDetails[accountID].login. For chats started with these expensifail / not-yet-validated accounts, that login arrives empty from the backend OpenReport response, so the email row is hidden and the name falls back to "Hidden". This is a backend issue — the App side behaves correctly.

Why it's not an App bug:

• When you start the chat, the App optimistically stores the typed-in email as the participant's login (src/libs/actions/Report/index.ts:1777-1781). At that instant the email would display.
• After the OpenReport API response merges into Onyx, the participant's login ends up empty. There is no App code that clears the login on success — so the empty value comes from the backend response's personal-details payload for that account (most likely because the address isn't a validated/existing user, so its login isn't shared).
• ProfilePage only shows the email when login is truthy (src/pages/ProfilePage.tsx:244-255), and getDisplayNameOrDefault returns "Hidden" when both displayName and login are empty (src/libs/PersonalDetailsUtils.ts:99). The header → profile navigation passes only the accountID, no login param (src/libs/ReportUtils.ts:6185), so the page has no client-side email to fall back to.

Recommendation: This needs a backend fix outside the App repo — the API isn't returning the participant's login in the personal-details payload for newly-invited / unvalidated accounts in a 1:1 DM. It should be escalated to an internal engineer to investigate the OpenReport personal-details serialization for these accounts. There is no clean App-only fix, since once the backend omits the login the client no longer has the email anywhere accessible by accountID.

Likely related (same "Hidden for non-existing/unvalidated email" family):

• Invoice - Hidden appears on participant list after selecting non-existing email #90655 — "Hidden appears on participant list after selecting non-existing email"
• [$250] Workspace - Primary login displayed as hidden after merged with other account #91592 — "Primary login displayed as hidden after merged with other account"

Investigation details

Symptom: Start chat with an expensifail address (e.g. applausetester+testemail@applause.expensifail.com) → open conversation → click the chat header. The profile RHP shows "Hidden" and no email, instead of an "Email" row with the address.

Evidence chain:

1. Header click on a 1:1 DM → navigateToDetailsPage → PROFILE.getRoute(accountID) with no login param (ReportUtils.ts:6179-6187).
2. ProfilePage resolves details = personalDetails[accountID] and login = details?.login ?? '' (ProfilePage.tsx:107-127). Email row only renders when login is truthy.
3. getDisplayNameOrDefault falls back to "Hidden" when displayName + login are both empty (PersonalDetailsUtils.ts:88-99).
4. The Start-chat flow (navigateToAndOpenReport → openReport) writes optimistic personalDetails[accountID] = { login, displayName: login, isOptimisticPersonalDetail: true } (Report/index.ts:1777-1781). successData for openReport only nulls pendingFields/errorFields — it never touches the login. So the empty login must arrive via the backend personal-details merge in the API response.

Alternative considered: an optimistic-vs-real accountID mismatch (optimistic detail orphaned under generateAccountID(login) while the page reads the real backend accountID). Either way the displayed account's backend login is empty, so the conclusion is unchanged: the backend isn't sharing the login for these accounts.

Confidence: High that the App is not at fault (optimistic login is set and never cleared client-side). Medium on the exact backend location — not yet confirmed against production logs.

---

Next Steps: This appears to be a backend/internal issue rather than an App code change. An internal engineer should confirm the OpenReport personal-details payload for unvalidated/non-existing accounts. Reply with @MelvinBot <your feedback> to refine this analysis.

[ijmalik]

Proposal

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

When a user starts a chat with an expensifail/unvalidated account (e.g., applausetester+testemail@applause.expensifail.com) and then views the profile details in the Right‑Hand Panel (RHP), the email field is hidden and the profile name displays as "Hidden". The email address should be displayed in the email field, and the profile name should fall back to the email address instead of "Hidden".

What is the root cause of that problem?

1. When a new chat is started with an unvalidated email, the App optimistically creates a participant record in Onyx PERSONAL_DETAILS_LIST with the login and displayName set to the entered email address.
2. When the backend's OpenReport API response returns, it sends personal details of the unvalidated account with an empty login field (due to backend validation/privacy constraints).
3. The empty login merges into Onyx and overwrites the optimistic non‑empty login value.
4. Because login becomes empty:
   • ProfilePage.tsx hides the email row (since login is falsy).
   • getDisplayNameOrDefault returns "Hidden" because both displayName and login are empty.

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

We will make one primary change in PersonalDetailsUtils.ts. Inside the Onyx.connect callback for PERSONAL_DETAILS_LIST, we cache any non‑empty login values and, when an empty login arrives for an account we have seen before, we restore the cached email by creating a shallow copy of that personal details object. This avoids mutating a potentially frozen Onyx object and ensures all downstream selectors see the corrected email.

File: src/libs/PersonalDetailsUtils.ts

Original code (lines 21‑35):

let allPersonalDetails: OnyxEntry<PersonalDetailsList> = {};
let emailToPersonalDetailsCache: Record<string, PersonalDetails> = {};

Onyx.connect({
    key: ONYXKEYS.PERSONAL_DETAILS_LIST,
    callback: (val) => {
        const personalDetails = Object.values(val ?? {});
        allPersonalDetails = val;
        emailToPersonalDetailsCache = personalDetails.reduce((acc: Record<string, PersonalDetails>, detail) => {
            if (detail?.login) {
                acc[detail.login.toLowerCase()] = detail;
            }
            return acc;
        }, {});
    },
});

New code:

let allPersonalDetails: OnyxEntry<PersonalDetailsList> = {};
let emailToPersonalDetailsCache: Record<string, PersonalDetails> = {};
const cachedLogins = new Map<number, string>();

Onyx.connect({
    key: ONYXKEYS.PERSONAL_DETAILS_LIST,
    callback: (val) => {
        allPersonalDetails = val;
        if (!val) {
            emailToPersonalDetailsCache = {};
            cachedLogins.clear();
            return;
        }

        // Cache incoming valid logins, and restore missing logins for existing cached records in‑memory.
        // We create shallow copies to avoid mutating any potentially frozen Onyx objects.
        for (const accountIDStr in val) {
            const accountID = Number(accountIDStr);
            const details = val[accountID];
            if (!details) {
                continue;
            }
            if (details.login) {
                cachedLogins.set(accountID, details.login);
            } else if (cachedLogins.has(accountID)) {
                // Restore the cached login using a shallow copy to guarantee immutability
                val[accountID] = {
                    ...details,
                    login: cachedLogins.get(accountID),
                };
            }
        }

        const personalDetails = Object.values(val);
        emailToPersonalDetailsCache = personalDetails.reduce((acc: Record<string, PersonalDetails>, detail) => {
            if (detail?.login) {
                acc[detail.login.toLowerCase()] = detail;
            }
            return acc;
        }, {});
    },
});

What alternative solutions did you explore? (Optional)

1. Backend fix – Change the OpenReport API to return the participant's login for unvalidated accounts. This would be the ideal root‑cause fix, but it requires backend changes outside the App repo and may take longer to deploy.

2. Using Onyx.merge inside the listener – Attempting to merge restored logins back into Onyx from within the same Onyx.connect callback risks an infinite loop (merge triggers the callback again). Our in‑memory restoration using shallow copies avoids that problem entirely.

3. Route parameter fallback – Pass the email as a route parameter to the profile page. This only fixes the profile RHP, not the chat header or LHN display names, and is fragile.

4. Modifying getDisplayNameOrDefault – Adding extra checks on login is unnecessary because the primary fix ensures login is either a valid email or undefined/null. The existing if (personalDetails?.login) is already sufficient.

[melvin-bot]

Huh... This is 4 days overdue. Who can take care of this?

[melvin-bot]

6 days overdue. This is scarier than being forced to listen to Vogon poetry!

[melvin-bot]

Now this issue is 8 days overdue. Are you sure this should be a Daily? Feel free to change it!

[melvin-bot]

12 days overdue now... This issue's end is nigh!

[melvin-bot]

this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[melvin-bot]

This issue has not been updated in over 14 days. eroding to Weekly issue.