[Due for payment 2026-04-20] [$250] Workspace chat - Reports jump we create new empty report

[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.40-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84696
Email or phone of affected tester (no customers): gocemate+b215490617@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 10/Chrome
App Component: Chat Report View

Action Performed:

1. Go to Workspace chat
2. Create empty report
3. Create another empty report

Expected Result:

Reports should not jump

Actual Result:

Reports jump we create new empty report

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.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/~022034600696385302145
• Upwork Job ID: 2034600696385302145
• Last Price Increase: 2026-03-19

[MelvinBot]

Proposal

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

When a user goes to a Workspace chat and creates empty reports, existing reports in the LHN "jump" (visually shift position). This happens on each empty report creation, making the experience jarring.

What is the root cause of that problem?

The jumping is caused by an LHN category change on the parent workspace chat combined with disabled scroll anchoring in the FlashList.

Here's the chain of events:

1. When an empty expense report is created, buildNewReportOptimisticData (src/libs/actions/Report/index.ts:3523) calls getOutstandingChildRequest() on the new optimistic report.

2. getOutstandingChildRequest (src/libs/ReportUtils.ts:11556-11560) evaluates the shouldBeManuallySubmitted path:

   isPaidGroupPolicy(policy) && !policy.harvesting.enabled && isOpenReport(iouReport)
   

   For workspaces with manual submission, this returns {hasOutstandingChildRequest: true} — even though the report is empty with zero transactions.

3. This value is optimistically merged into the parent workspace chat (Report/index.ts:3558-3561):

   value: {iouReportID: reportID, ...outstandingChildRequest}
   

4. The parent's hasOutstandingChildRequest: true triggers requiresAttention: true via getReasonAndReportActionThatRequiresAttention (ReportUtils.ts:4352-4354).

5. In categorizeReportsForLHN (SidebarUtils.ts:459-463), requiresAttention moves the parent from the nonArchivedReports group (sorted by date, mid-list position) to the pinnedAndGBRReports group (sorted alphabetically, appears at the top of the LHN). This is the primary cause of the visual jump — the parent report teleports to a different position, shifting everything below it.

6. The FlashList in LHNOptionsList has maintainVisibleContentPosition explicitly disabled (LHNOptionsList.tsx:422), so no scroll compensation occurs when items reorder — the scroll offset stays fixed while items shift around it.

Additionally on web (the reported platform), when navigating to the new hidden expense report, if it's not in orderedReportIDs, the entire list is regenerated from scratch (useSidebarOrderedReports.tsx:296-310), which can compound the re-ordering.

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

Fix getOutstandingChildRequest in src/libs/ReportUtils.ts to not flag empty expense reports (with no transactions and zero total) as outstanding child requests.

In the shouldBeManuallySubmitted block at line 11556-11561, add a check that the report actually has a non-zero total or transactions before returning hasOutstandingChildRequest: true. An empty report has nothing to submit, so it should not be considered an "outstanding child request." This prevents the parent workspace chat from being moved to the GBR/pinned category when there's nothing actionable.

This is the most targeted fix — it addresses the root cause (the category change that causes the largest visual jump) without modifying scroll behavior or sort logic that other features depend on.

What alternative solutions did you explore? (Optional)

1. Enable maintainVisibleContentPosition on the LHN FlashList — This would provide scroll anchoring when items are inserted/reordered above the viewport. However, it was explicitly disabled (likely for known issues on certain platforms, as evidenced by the custom iOS FlatList wrapper handling this prop). Enabling it could introduce regressions.

2. Defer hasOutstandingChildRequest until the server responds — Instead of setting it optimistically, wait for the server to confirm the report creation. This would avoid the intermediate state but would make the GBR indicator appear with a delay for legitimate cases.

---

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a user creates multiple empty reports from a Workspace chat, existing reports in the LHN visually "jump" (shift position). Each new empty report creation causes a jarring reorder of the sidebar list.

What is the root cause of that problem?

The jump happens because empty workspace rooms are removed from the LHN the moment they lose focus. The function reasonForReportToBeInOptionList() in ReportUtils has a special case that always shows the currently focused report regardless of its state. But once focus moves away, the same function's empty-chat hiding block at lines 9589–9601 kicks in and removes the now-unfocused empty report from the sidebar entirely.

A newly created workspace room is considered "empty" because its only report action is CREATED, which is explicitly excluded from visible actions in getLastVisibleAction() in ReportActionsUtils. So generateIsEmptyReport() returns true for any fresh workspace room.

When focus changes (user creates Report B after Report A), useSidebarOrderedReports at lines 164–168 re-evaluates both the old and new reports. Report A, now unfocused and empty, fails the empty-chat check and is removed from the LHN. This removal shifts all remaining items, and since maintainVisibleContentPosition is disabled on the FlashList in LHNOptionsList, no scroll compensation occurs — producing the visible jump.

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

In ReportUtils, add !isUserCreatedPolicyRoom(report) to the empty-chat hiding condition. User-created workspace rooms should stay visible in the LHN even when empty, since the user explicitly created them and removing them on defocus is both unexpected and causes the visual jump:

if (
    excludeEmptyChats &&
    isEmptyChat &&
    isChatReport(report) &&
    !isPolicyExpenseChat(report) &&
    !isTripRoom(report) &&
    !isUserCreatedPolicyRoom(report) &&  // <-- prevent hiding user-created rooms
    !isConciergeChatReport(report) &&
    !isSystemChatReport &&
    !isSelfDMWithVisiblePreference &&
    canHideReport
) {
    return null;
}

This is a single-line, low-risk change that prevents the removal that causes the jump.

What alternative solutions did you explore? (Optional)

The existing MelvinBot proposal targets getOutstandingChildRequest() and the GBR/pinned category reassignment of the parent workspace chat. That's a valid secondary contributor, but the primary visual jump comes from empty rooms being removed from the LHN entirely when they lose focus — a different mechanism. Even if the GBR fix is applied, the disappearance of unfocused empty rooms will still cause items to shift. This proposal addresses the removal itself, which is the more fundamental cause. Both fixes could coexist, but this one alone eliminates the reported jump by keeping the room in the list rather than letting it vanish and reappear.

[shivang-goliyan]

Proposal

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

When you create empty expense reports in a Workspace chat, the existing reports in the LHN jump around. The parent workspace chat gets incorrectly flagged as needing attention (GBR), which moves it from the date-sorted section to the alphabetically-sorted pinned/GBR section — causing the visual teleport.

What is the root cause of that problem?

The issue is in getOutstandingChildRequest in src/libs/ReportUtils.ts (line 11534-11538). When an empty expense report is created via buildOptimisticEmptyReport (total: 0, state: OPEN), the function checks shouldBeManuallySubmitted — which passes for any open report on a manual-submission workspace. But there's no check for whether the report actually has money in it. So even a blank report with zero total gets flagged as hasOutstandingChildRequest: true.

That result gets spread into the parent workspace chat at Report/index.ts:3555, triggering requiresAttention: true via getReasonAndReportActionThatRequiresAttention (ReportUtils.ts:4350-4353). Then categorizeReportsForLHN (SidebarUtils.ts:459-462) moves the parent from nonArchivedReports (date-sorted) to pinnedAndGBRReports (alpha-sorted). With maintainVisibleContentPosition disabled on the FlashList (LHNOptionsList.tsx:422), there's no scroll compensation — the parent teleports.

The non-expense (IOU) path at line 11525-11528 already guards against this with reimbursableSpend !== 0. The expense report path is missing the equivalent.

This is a regression from PR #74644 (commit f28c51e68fa, merged Nov 23 2025). That PR added the isOpenReport check to prevent GBR on submitted scan expenses but didn't add a total guard for empty reports.

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

In getOutstandingChildRequest at src/libs/ReportUtils.ts:11536, change if (shouldBeManuallySubmitted) to if (shouldBeManuallySubmitted && iouReport.total !== 0) — matching the existing IOU path pattern.

An empty report with total: 0 has nothing to submit — it shouldn't be flagged as outstanding. When a transaction is added later, getOutstandingChildRequest gets re-called by IOU action callers (IOU/index.ts:1926, 4346, 8285) with the updated total, so the flag will be correctly set at that point. Negative totals (credits) still return true since they need attention.

What alternative solutions did you explore? (Optional)

I looked at adding the total check downstream in getReasonAndReportActionThatRequiresAttention instead, but the bad data (hasOutstandingChildRequest: true) would still be written to Onyx — every consumer would need its own guard. Fixing at the source is cleaner. I also considered skipping the getOutstandingChildRequest call entirely in buildNewReportOptimisticData for empty reports, but the bug lives in the function itself (which has 5 callers across Report/index.ts and IOU/index.ts), not in any single caller.

[thelullabyy]

Proposal

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

Reports jump we create new empty report

What is the root cause of that problem?

When the preview is mounted, an ActivityIndicator is always rendered briefly since currentWidth need to wait for onLayout event. This UI renders a fixed height of 269px

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 999 to 1012 in e2277ac

	{!currentWidth || shouldShowLoading || shouldShowLoadingDeferred ? (
	<View
	style={[
	{
	height: CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.WIDE_HEIGHT,
	minWidth: shouldUseNarrowLayout
	? CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_NARROW_WIDTH
	: CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_WIDE_WIDTH,
	},
	styles.justifyContentCenter,
	styles.mtn1,
	]}
	>
	<ActivityIndicator

After that, the empty UI is displayed with a height of 168px, which causes the UI to jump based on the changed height of the preview.

App/src/components/ReportActionItem/MoneyRequestReportPreview/EmptyMoneyRequestReportPreview.tsx

Line 20 in e2277ac

<View style={[styles.emptyStateMoneyRequestPreviewReport, styles.justifyContentCenter, styles.alignItemsCenter]}>

App/src/styles/index.ts

Line 5312 in e2277ac

height: 168,

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

Update the height of the wrap view here to 168 if shouldShowEmptyPlaceholder is true. Because shouldShowEmptyPlaceholder is only true when the showLoading is false, this ensures that the empty UI will be displayed after the loading indicator. If we want to keep the mtn1 in this case, we can increase the height to 172

<View
                                            style={[
                                                {
                                                    height: shouldShowEmptyPlaceholder ? 168 : CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.WIDE_HEIGHT,
                                                    minWidth: shouldUseNarrowLayout
                                                        ? CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_NARROW_WIDTH
                                                        : CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_WIDE_WIDTH,
                                                },
                                                styles.justifyContentCenter,
                                                !shouldShowEmptyPlaceholder && styles.mtn1,
                                            ]}
                                        >

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 999 to 1012 in e2277ac

	{!currentWidth || shouldShowLoading || shouldShowLoadingDeferred ? (
	<View
	style={[
	{
	height: CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.WIDE_HEIGHT,
	minWidth: shouldUseNarrowLayout
	? CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_NARROW_WIDTH
	: CONST.REPORT.TRANSACTION_PREVIEW.CAROUSEL.MIN_WIDE_WIDTH,
	},
	styles.justifyContentCenter,
	styles.mtn1,
	]}
	>
	<ActivityIndicator

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[ZhenjaHorbach]

Thanks for your proposals
I will check today or tomorrow!

[chengyixu]

Proposal

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

When a user creates a new empty report from the Workspace chat view, the report list jumps (scrolls unexpectedly or reorders), disrupting the user's current scroll position and causing a jarring visual experience.

What is the root cause of that problem?

When a new report is optimistically added to Onyx, the LHN/report list re-renders and the sort order changes because the new empty report is inserted at the top (most recent) position. If the user was scrolled down the list, the FlatList re-renders without preserving contentOffset, which causes the visible window to jump. Additionally, if the list uses inverted rendering or a getItemLayout cache that becomes stale after the insert, the scroll position calculation is off by one item height, producing a visible jump.

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

1. When inserting a new report into the list optimistically, use FlatList's maintainVisibleContentPosition prop to prevent scroll jumps when items are prepended.
2. Ensure the keyExtractor returns a stable, unique key per report so React does not confuse the new empty report with an existing row and trigger an incorrect re-order animation.
3. After the new report is created and the user is navigated to it (Workspace chat for that report), the original list scroll position should be restored when the user navigates back — save and restore the scroll offset in the list component's navigation state.
4. Add a regression test: create a new empty report from Workspace chat, then navigate back to the list, and assert the scroll position is within one item height of where it was before creation.

What alternative solutions did you explore? Why did you reject them?

• Disabling list animations during report creation: rejected because it removes useful feedback without fixing the underlying scroll position issue.