[$250] Dev - Welcome header is showing after the contents

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @ShridharGoel
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create a new workspace
2. Navigate to workspace chat
3. Create a manual expense
4. Observe the welcome message

Expected Result:

Welcome header should show before all the messages

Actual Result:

Welcome header is showing after the messages (Expense report)

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mkhutornyi

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022033698750291113884
• Upwork Job ID: 2033698750291113884
• Last Price Increase: 2026-03-17

[MelvinBot]

Proposal

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

When a user creates a new workspace, navigates to the workspace chat, and creates a manual expense, the welcome header (avatars + "This is the beginning of your chat with...") appears below the expense report preview instead of at the top of the chat.

What is the root cause of that problem?

The workspace chat uses ReportActionsList with an InvertedFlatList where actions are sorted descending (newest first). The CREATED action (welcome header) is guaranteed to sort last in this array via explicit logic in getSortedReportActions (ReportActionsUtils.ts:644-646), which in the inverted list places it at the visual top.

However, the issue occurs because of a scroll positioning race during the optimistic expense creation flow. When the REPORT_PREVIEW action is optimistically added to the workspace chat:

1. ReportActionsList receives the updated sortedVisibleReportActions with CREATED at the end (index 1) and REPORT_PREVIEW at the start (index 0)
2. The list auto-scrolls to show the newest content via shouldScrollToEndAfterLayout (ReportActionsList.tsx:819). For workspace chats, hasCreatedActionAdded is false (because shouldAddCreatedAction at ReportActionsView.tsx:167 only generates optimistic CREATED actions for money request/invoice reports, not workspace chats), so the condition !hasCreatedActionAdded is always true
3. This causes reportScrollManager.scrollToEnd() to fire, which in an inverted FlatList scrolls to show the oldest content (the CREATED/welcome header) at the bottom of the viewport instead of anchoring the newest message at the bottom

The root issue is that shouldScrollToEndAfterLayout combined with !hasCreatedActionAdded being always true for workspace chats causes an unwanted scrollToEnd() call after the expense is created, placing the welcome header at the bottom of the visible area with the expense report above it.

Additionally, the scrollToEnd behavior is gated by !hasCreatedActionAdded || isOffline at lines 409 and 819 of ReportActionsList.tsx. Since workspace chats always have hasCreatedActionAdded = false, this scroll behavior fires unconditionally after layout, disrupting the expected scroll position.

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

The fix should ensure that after an expense is created in a workspace chat, the list maintains proper scroll position with the welcome header at the top and the newest message (expense) visible at the bottom.

Specifically, in ReportActionsList.tsx, the onTrackScrolling callback and onLayoutInner callback should account for the fact that workspace chats (and other non-money-request reports) never have hasCreatedActionAdded = true. The shouldScrollToEndAfterLayout logic should be refined to not trigger scrollToEnd() when the list already contains a CREATED action in the visible actions (i.e., when sortedVisibleReportActions already includes a CREATED action from Onyx rather than an optimistically added one).

The condition at lines 409 and 819 could be updated from:

shouldScrollToEndAfterLayout && (!hasCreatedActionAdded || isOffline)

to also check whether the CREATED action already exists in the visible actions, preventing the scroll when the welcome header is already present and properly positioned.

What alternative solutions did you explore? (Optional)

1. Making shouldAddCreatedAction true for workspace chats: This would mean generating an optimistic CREATED action for workspace chats too, which would make hasCreatedActionAdded properly transition from true to false. However, workspace chats always have their CREATED action stored in Onyx from workspace creation, so generating another one would be redundant and could cause duplicate CREATED actions.

2. Adjusting sort logic: The sort logic in getSortedReportActions is already correct — CREATED is explicitly pinned to the oldest position regardless of timestamp. The issue is not with data ordering but with scroll behavior after layout.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot 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 - @mkhutornyi (External)

[melvin-bot]

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

[jainam884]

Proposal

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

In the expense report flow triggered from a workspace chat, the welcome header (CREATED action) can appear after the expense content instead of before it. This makes the report look out of order right after creation.

What is the root cause of that problem?

The initial "focus-to-top" flow for money request/invoice reports depends on shouldScrollToEndAfterLayout. That flag starts as true for these report types, and scrollToEnd() is expected to run once to place the oldest CREATED action at the top.

However, the same gate is also used in onTrackScrolling to immediately set that flag to false when !hasCreatedActionAdded. For reports that already have a CREATED action (so hasCreatedActionAdded is false), an early mount scroll event can clear the flag before onLayoutInner executes the scrollToEnd() call. That race leaves the list at the default position, so the welcome header can render below newer content.

App/src/pages/inbox/report/ReportActionsView.tsx

Line 127 in 1d43910

const shouldAddCreatedAction = !isCreatedAction(lastAction) && (isMoneyRequestReport(report) || isInvoiceReport(report) || isInitiallyLoadingTransactionThread);

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 366 to 367 in 1d43910

	if (shouldScrollToEndAfterLayout && (!hasCreatedActionAdded || isOffline)) {
	setShouldScrollToEndAfterLayout(false);

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 762 to 765 in 1d43910

	if (shouldScrollToEndAfterLayout && (!hasCreatedActionAdded || isOffline)) {
	requestAnimationFrame(() => {
	reportScrollManager.scrollToEnd();
	});

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

1. Make the initial scrollToEnd() execution authoritative instead of relying on a scroll event race:

• Track whether the one-time initial scrollToEnd() was actually scheduled/executed (e.g., a ref).
• Set shouldScrollToEndAfterLayout(false) immediately after scheduling/executing that one-time scroll.

2. Stop clearing shouldScrollToEndAfterLayout in onTrackScrolling before the initial programmatic scroll has run.

• Keep onTrackScrolling as a cleanup path only after the initial mount scroll is completed.

3. Keep the existing prevHasCreatedActionAdded && !hasCreatedActionAdded transition behavior for optimistic-created-action flows, but decouple it from the "already-has-created-action" path so both scenarios are deterministic.

This removes the ordering race and ensures the welcome header remains above report contents on first render.

What alternative solutions did you explore? (Optional)

1. Always inject an optimistic CREATED action for these reports.

• Rejected because it can duplicate CREATED behavior and adds unnecessary synthetic actions when a real CREATED already exists.

2. Change report-action sorting rules.

• Rejected because sorting is already designed to keep CREATED as the oldest display action; the failure is in initial scroll state timing, not sort order.

[janekissington]

Proposal

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

When a user creates a new workspace, navigates to the workspace chat, and creates a manual expense, the welcome header (CREATED action) appears below the expense report preview instead of above it.

What is the root cause of that problem?

Both existing proposals attribute this to the shouldScrollToEndAfterLayout / scrollToEnd() logic in ReportActionsList.tsx. However, that analysis does not hold for workspace chats. Here is why:

In ReportActionsList.tsx (line 237), shouldFocusToTopOnMount is computed as:

isTransactionThreadReport || isMoneyRequestOrInvoiceReport

A workspace chat is neither a transaction thread nor a money request/invoice report. So shouldFocusToTopOnMount is false, which means shouldScrollToEndAfterLayout is initialized to false (line 239) and is never set to true. The scroll-to-end gates at lines 409, 531, 819, and 911 all check shouldScrollToEndAfterLayout and therefore never fire for workspace chats. The justifyContentEnd style at line 920 is also not applied.

The actual root cause is in the scrollToBottomForCurrentUserAction callback (lines 559-596). When the user creates an expense from the workspace chat, a REPORT_PREVIEW action is optimistically added. The new-action event fires this callback:

1. At line 577, it looks up the REPORT_PREVIEW's index in sortedVisibleReportActionsRef.current. Due to the InteractionManager.runAfterInteractions delay, the ref may not yet reflect the updated data (the ref is synced via useEffect at line 555-557, which also runs asynchronously after render). If the ref still holds the old array (just CREATED), findIndex returns -1.

2. At line 578-586, for a REPORT_PREVIEW with index > 0 false (index is 0 or -1), it falls through to scrollToBottom() (offset 0). It then calls setIsScrollToBottomEnabled(true) at line 595.

3. The setIsScrollToBottomEnabled(true) state update triggers a re-render. On the next layout (onLayoutInner, line 812-826), scrollToBottom() is called again.

4. Here is the problem: between the optimistic data update (step 1) and the final scroll (step 3), the InvertedFlatList's maintainVisibleContentPosition is undefined for this scenario (line 119-134 of useFlatListScrollKey.ts — it is only active when initialScrollKey is set). Without maintainVisibleContentPosition, when a new item is prepended to the data array (REPORT_PREVIEW is at index 0, prepended before CREATED at index 1), the FlatList does not adjust its scroll offset to account for the new item's height. The content shifts, and the subsequent scrollToBottom() at offset 0 anchors the viewport to the wrong visual position — showing the CREATED action at the bottom of the viewport instead of the top.

This is a timing-dependent issue that manifests specifically when: (a) the report is a workspace chat (no shouldScrollToEndAfterLayout), (b) the list has very few items (1 CREATED action), and (c) the viewport is taller than the content, so the content shift from prepending the REPORT_PREVIEW is noticeable.

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

The fix should be in the scrollToBottomForCurrentUserAction callback in ReportActionsList.tsx. When a REPORT_PREVIEW action is added to a non-money-request, non-transaction-thread report (like a workspace chat), the callback should not call scrollToBottom() immediately. Instead, it should let the FlatList settle with the new data first, then scroll.

Specifically, in scrollToBottomForCurrentUserAction (lines 578-586), when the action is a REPORT_PREVIEW and the report is not a money request or transaction thread report, delay the scroll until after the FlatList has re-rendered with the new data by waiting for the next requestAnimationFrame after the state update, rather than scrolling immediately and relying on setIsScrollToBottomEnabled for a follow-up scroll that races with the content layout.

Remove the setIsScrollToBottomEnabled(true) call at line 595 for the REPORT_PREVIEW case and instead use a single deferred scrollToBottom() via requestAnimationFrame that fires after the FlatList has incorporated the new item into its layout. This eliminates the double-scroll race between scrollToBottomForCurrentUserAction and onLayoutInner.

What alternative solutions did you explore? (Optional)

1. Enabling maintainVisibleContentPosition for all inverted lists regardless of initialScrollKey. This would prevent the content shift when items are prepended, but it would change scrolling behavior globally and could introduce regressions in other report types that rely on the current prepend-without-adjustment behavior.

2. Adding workspace chats to the shouldFocusToTopOnMount check so they also get the scrollToEnd flow. This would work but is semantically wrong — workspace chats do not need the money-request-report-style "scroll to oldest action" behavior on mount.

[melvin-bot]

📣 @janekissington! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[janekissington]

Contributor details
Your Expensify account email: janekissington@outlook.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0155095179172b2f4d

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!