Rooms - Divider between rooms disappears after changing sorting order

[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+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rooms.
3. Click Name on the table header.

Expected Result:

Divider between rooms will not disappear after changing sorting order.

Actual Result:

Divider between rooms disappears after changing sorting order.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7165805_1780004836038.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7165805

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/594bb14479d65562de1cf13af7766d31b8369cafb72f80cb991be5151aee7f82

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

After #91056, the new WorkspaceRoomsTable renders rows through the shared Table + FlashList infrastructure. Whether a row paints a divider (borderBottom) vs. rounded bottom corners (tableBottomRadius) is decided in Table/TableRow.tsx:59-60 from a rowIndex prop passed in by renderItem:

const rowCount = processedData.length;
const isLastRow = rowIndex === rowCount - 1;

WorkspaceRoomsTable forwards FlashList's index straight through:

• WorkspaceRoomsTable/index.tsx:49-55 — renderItem with rowIndex={index}, no key
• WorkspaceRoomsTable/index.tsx:66 — keyExtractor={(row) => row.reportID}

When the user clicks the Name header, sorting is toggled and processedData is re-ordered (Table.tsx:157, middlewares/sorting.ts:148-152). The rooms keep the same reportID keys, so FlashList recycles the row views; the recycled row components retain their original rowIndex value while landing in new visual positions. As a result rowIndex === rowCount - 1 evaluates true for whichever row was originally last (not the new visually-last row), so that row keeps tableBottomRadius and loses its borderBottom — the divider disappears.

Strong hint that this footgun is real: the analogous WorkspaceCompanyCardsTable/index.tsx:290 already works around it with key={${item.cardName}_${index}} — that key change forces React to remount the row when its index changes.

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

Fix it at the Table layer so every consumer is correct, not just WorkspaceRoomsTable:

In Table/TableRow.tsx, stop trusting the rowIndex prop for the last-row decision. Read the current rendered order from context and derive "is last" by comparing the row's identity (e.g. the value of keyExtractor(item)) to the last entry of processedData. Pass item (or its key) into Table.Row so the comparison is possible. This eliminates the dependence on a recycled-prop value entirely.

If a minimal hot-fix is preferred for the deploy blocker, the smallest surgical change is to make the row's React key depend on index in WorkspaceRoomsTable/index.tsx (same workaround already used by WorkspaceCompanyCardsTable). Then follow up with the proper Table.Row fix above so future tables don't repeat this.

What alternative solutions did you explore? (Optional)

• Forcing FlashList to invalidate recycling via extraData={activeSorting} in Table/TableBody.tsx:84-90. Works but couples the body to sort-state and still leaves the brittle "trust the prop" assumption in Table.Row.
• Per-row workaround key={${reportID}_${index}} in only WorkspaceRoomsTable. Solves this issue but is a per-consumer footgun.

Investigation details

Confidence: Medium. Code-level analysis based on the Table flow added in #91056. Not confirmed against a live repro yet — would recommend a quick manual check on staging (Workspace settings → Rooms, click Name header) before committing to the fix, and confirming via React DevTools that recycled rows keep a stale rowIndex.

Symptoms explained by hypothesis:

• "Divider between rooms disappears after changing sorting order" → the row that was originally last keeps isLastRow=true (stale rowIndex) and renders tableBottomRadius with no borderBottom, so the divider above the new visually-last row is missing.
• Only reproducible on staging because the feature is behind the workspaceRoomsPage beta (PR [Behind Beta] Add workspace rooms list rows #91056).

Related issues scan (open): none other than this one.

---

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