Rooms - Created by field remains empty on "Rooms" page after creating private room.

[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: 9.3.89-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91056
Email or phone of affected tester (no customers): applausetester+ib0005@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 / Chrome
App Component: Workspace Settings

Action Performed:

Prerequisite: Logged in with expensifail account.
Prerequisite 2: Account has at least one workspace.

1. Open the staging.new.expensify.com wesbite.
2. Click on FAB > "Start Chat" > "Room"
3. Create a new private room.
4. Navigate to workspaces and open the workspace where room was created.
5. Navigate to "Rooms"
6. Note that the just created room is visible on rooms list.
7. Note that "Created By" field remains empty on the just created room.

Expected Result:

After creating a new private room, "Created By" field on rooms list, should display the user´s email.

Actual Result:

New created room appears on rooms list on "Rooms" section, but "Created By" field remains empty.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7166020_1780024966866.Created_By.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7166020

Issue Owner

Current Issue Owner: @shubham1206agra

[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/4c859c3b083595f11ba82669ec89175706ea56a65971448c1f0cca45d5898860

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #91056

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

[MelvinBot]

Proposal

What is the root cause of that problem?

In WorkspaceNewRoomPage.tsx:132, the optimistic data for a newly created private room hardcodes ownerAccountID: CONST.REPORT.OWNER_ACCOUNT_ID_FAKE (which equals 0 — see CONST/index.ts:1856).

The new rooms list rendered by PR #91056 reads the owner like this in WorkspaceRoomsPage.tsx:60:

const ownerDetails = report.ownerAccountID ? personalDetails?.[report.ownerAccountID] : undefined;

For the freshly-created room, report.ownerAccountID is 0, which is falsy, so ownerDetails is undefined and ownerDisplayName becomes ''. The row in WorkspaceRoomsTableRow.tsx only renders the "Created By" cell when item.ownerDisplayName is truthy, so the column stays blank.

The addPolicyReport success/failure data in Report/index.ts:4286-4319 only clears pendingFields — it never replaces the sentinel ownerAccountID, so the room stays with ownerAccountID = 0 in Onyx for the rest of the session (until a fresh fetch overwrites it).

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

Set the optimistic ownerAccountID to the current user's accountID in WorkspaceNewRoomPage.tsx:127-138 when calling buildOptimisticChatReport — the creator of the room is always the current user, so currentUserAccountID (already computed on line 124) is the correct value, and there is no need for the sentinel here. With a real accountID in place, the lookup in WorkspaceRoomsPage.tsx will resolve the user's personalDetails and the "Created By" column will populate immediately on optimistic creation, and stay correct after the backend response.

What alternative solutions did you explore? (Optional)

Falling back to the current user in WorkspaceRoomsPage.tsx when report.ownerAccountID is missing or equals OWNER_ACCOUNT_ID_FAKE. This works but couples the rooms page to an assumption about who the creator must be — the source-side fix is cleaner and also benefits any future consumer that reads ownerAccountID from a freshly created room.

Supporting evidence

• The OWNER_ACCOUNT_ID_FAKE sentinel is used as a "backend will fill this in" placeholder, but AddWorkspaceRoom's successData (linked above) does not overwrite ownerAccountID — so the optimistic value sticks until a separate fetch repopulates the report.
• Note that an existing pattern in Report/index.ts:1727-1731 already gates on newReportObject.ownerAccountID && newReportObject.ownerAccountID !== CONST.REPORT.OWNER_ACCOUNT_ID_FAKE, which confirms the codebase treats 0 as "no real owner yet".
• Symptoms match: every newly created private room shows empty "Created By", existing rooms (loaded via OpenPolicyRoomsPage with the backend's real ownerAccountID) display correctly. The bug is therefore scoped to the optimistic creation flow, not the rooms list rendering itself.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92054#issuecomment-MELVIN_COMMENT_ID) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.