[$250] Message in IOU is not scrolled to when navigating via link, "submitted" not shown

[nlemma]

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.51-5
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86719 step 2 in Re-fetch triggers
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iPhone 15 iOS 26.3.1
App Component: Other

Action Performed:

1. Sign in to ND as User A on the main testing device, and User B on secondary device
2. As User A, create a workspace, add User B as a member
3. As User B, navigate to the workspace chat
4. Create a manual expense, open expense details, click Submit button
5. Send three messages in the expense details
6. Right click on the 3rd message - Copy link - send the link in 1:1 chat with User A
7. As User A, open 1:1 chat with User B, tap the link from step 6

Expected Result:

The linked message is scrolled to

Actual Result:

User is navigated to the expense details, but the message is not scrolled to (happens, when navigating for the first time). "Submitted" system message does not appear in the expense details thread when navigating via another message link.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7119277_1775069325794.Message_not_scrolled.MP4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022039454831347450891
• Upwork Job ID: 2039454831347450891
• Last Price Increase: 2026-04-22

[MelvinBot]

Proposal

What is the root cause of that problem?

When navigating to an IOU/expense thread via a copied message link, the ReportFetchHandler component at src/pages/inbox/ReportFetchHandler.tsx:159-164 has an effect that detects "one-transaction threads" and immediately clears reportActionID from the route params:

useEffect(() => {
    if (!transactionThreadReportID || !route?.params?.reportActionID || !isOneTransactionThread(childReport, report, linkedAction)) {
        return;
    }
    navigation.setParams({reportActionID: ''});
}, [transactionThreadReportID, route?.params?.reportActionID, linkedAction, ...]);

This has two consequences:

1. Scroll-to fails: The reportActionID is used as initialScrollKey in the InvertedFlatList (ReportActionsList.tsx:902). When cleared, the FlatList remounts without a scroll anchor and renders from the newest message instead of the linked one.

2. "Submitted" disappears: The main fetch effect at ReportFetchHandler.tsx:224-229 depends on reportActionIDFromRoute. When that is cleared to '', it re-triggers openReport without a reportActionID, causing the server to return the newest page of actions rather than actions centered around the linked message. The "Submitted" system action, which is a separate report action in the timeline, may be chronologically outside this newest page and not included in the returned data. Additionally, usePaginatedReportActions returns only the continuous page chain -- so the "Submitted" action falls outside the displayed window.

This issue was likely exacerbated by PR #86719 ("decompose ReportScreen 6b: extract fetch controller"), which moved this clearing effect from ReportScreen into the separate ReportFetchHandler child component. Previously, the clearing effect and the scroll/linking logic all ran in the same component (ReportScreen) within the same render cycle. Now they run in separate sibling components (ReportFetchHandler vs ReportActionsView), introducing a timing gap where reportActionID can be cleared before the scroll-to-linked-message logic in ReportActionsView has a chance to position the list.

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

The one-transaction-thread effect at ReportFetchHandler.tsx:159-164 should not clear reportActionID when the linked message belongs to the transaction thread that the one-transaction view is about to display inline. Instead, the reportActionID should be preserved so that:

1. The initialScrollKey in ReportActionsList/MoneyRequestReportActionsList can position the list at the linked message.
2. The openReport API call retains the reportActionID so the server returns the correct page of actions around the linked message (including "Submitted").

The fix should modify the effect to only clear reportActionID when the user is navigating to a one-transaction thread and the linked action is the IOU parent action itself (which gets expanded into the transaction thread view), not when the linked action is a comment or system message within that thread.

What alternative solutions did you explore? (Optional)

An alternative would be to delay clearing reportActionID until after the scroll-to-linked-message logic has completed (e.g., using a ref or callback to signal completion). However, this would add unnecessary complexity -- the simpler approach is to not clear the reportActionID when it points to a message that will be displayed in the combined one-transaction view.

---

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.

Cat fact: Cats have a specialized collarbone that allows them to always land on their feet -- they can rotate their spine mid-fall at up to 100 RPM.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @abdulrahuman5196 (External)

[melvin-bot]

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

[KJ21-ENG]

Proposal

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

When opening an IOU message link (copied from inside expense details), the app navigates to the expense details thread but does not reliably scroll to the linked message on first open, and the "Submitted" system message can be missing from the loaded thread window.

What is the root cause of that problem?

The route reportActionID (used as the link anchor) is being cleared too early in one-transaction-thread navigation.

In ReportScreen, when the destination is detected as a one-transaction thread, this effect clears reportActionID immediately:

App/src/pages/inbox/ReportScreen.tsx

Lines 427 to 432 in 1d43910

	useEffect(() => {
	if (!transactionThreadReportID || !route?.params?.reportActionID || !isOneTransactionThread(childReport, report, linkedAction)) {
	return;
	}
	navigation.setParams({reportActionID: ''});
	}, [transactionThreadReportID, route?.params?.reportActionID, linkedAction, reportID, navigation, report, childReport]);

But reportActionIDFromRoute is also passed into openReport(...) as the server fetch anchor:

App/src/pages/inbox/ReportScreen.tsx

Line 563 in 1d43910

openReport(reportIDFromRoute, introSelected, reportActionIDFromRoute);

And it is used as initialScrollKey for the action list:

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

Line 868 in 1d43910

initialScrollKey={reportActionID}

So clearing it before initial load/positioning removes both:

1. the fetch focus around the linked action, and
2. the first-render scroll anchor to the linked action.

This matches the observed behavior from the issue media: the linked "Message 3" appears, but "Submitted" is not in the initially loaded window when entering via the link.

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

1. In one-transaction-thread link flows, do not clear reportActionID immediately on mount.
2. Keep reportActionID until initial linked-action positioning is complete (or until we confirm the linked action is visible), then clear it if needed for cleanup.
3. Scope this logic to link-navigation paths only so normal non-link report opening behavior is unchanged.
4. Add regression coverage for: copy link from an expense-thread message -> open link from 1:1 -> verify first open lands on linked message and still includes adjacent system actions like "Submitted" in the loaded timeline.

What alternative solutions did you explore? (Optional)

• Removing the one-transaction-thread reportActionID cleanup entirely would reduce this bug but risks stale route param side effects in other flows.
• A safer fix is deferred cleanup (after anchor usage), not immediate cleanup before fetch/scroll anchoring.

[bossco7598]

Contributor details:

• Name: Sean Ideozu
• Upwork profile: https://www.upwork.com/freelancers/bosscos
• Email: bossco7598@gmail.com

---

Proposal

Root cause:

This is a regression from PR #86719 (Re-fetch triggers). When navigating to an IOU report via a notification link or deep-link, ReportActionsView triggers a re-fetch of report actions. The scroll-to-linked-message logic runs on initial mount but does not re-run after the re-fetch completes — the list settles at default position (bottom or unread) rather than scrolling to the linked action.

Additionally, the submitted action (IOU with originalMessage.type === 'submit') may not render its label after the re-fetch resets the list, since the initial viewport position is not preserved through the loading cycle.

Files involved:

• src/pages/home/report/ReportActionsView.tsx — re-fetch lifecycle + scroll-to trigger
• src/components/ReportActionsList.tsx — scrollToIndex ref timing
• src/libs/ReportUtils.ts — getIOUReportActionMessage "submitted" label

Proposed fix:

1. In ReportActionsView.tsx, preserve the linkedReportActionID target through the re-fetch cycle. After the re-fetch loading state clears (when isLoading transitions true → false), re-trigger the scroll-to-index call with the same target instead of only running it on mount.
2. Prevent initialScrollIndex from being reset by the re-fetch loading state — gate the reset on linkedReportActionID being absent, not just on loading completing.
3. Ensure the "submitted" IOU action renders in the visible viewport once the scroll lands — the getIOUReportActionMessage logic is correct but the render is skipped when the action is outside the initial viewport post-re-fetch.

Impact: All platforms (iOS confirmed in issue). Single lifecycle fix in ReportActionsView.tsx scroll trigger.

[wildan-m]

Proposal

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

When navigating to an expense details thread via a copied message link, the "Submitted" system message does not appear and the linked message may not be scrolled to correctly.

What is the root cause of that problem?

When a user copies a message link from the one-transaction combined view (parent IOU report with the transaction thread inlined), the link URL points to the transaction thread report — not the parent IOU report. This is because getOriginalReportID in ReportActionsList detects that the comment action doesn't exist in the parent IOU report's raw Onyx actions, and returns the transaction thread's report ID:

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

Line 687 in 4195ea3

const originalReportID = getOriginalReportID(report.reportID, reportAction, reportActionsFromOnyx);

When another user taps this link, they navigate directly to the transaction thread report (type CHAT). In ReportActionsView, getOneTransactionThreadReportID is called to determine whether to merge parent actions:

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

Lines 119 to 122 in 4195ea3

	const transactionThreadReportID = useMemo(
	() => getOneTransactionThreadReportID(report, chatReport, allReportActions ?? [], isOffline, reportTransactionIDsForThread),
	[report, chatReport, allReportActions, isOffline, reportTransactionIDsForThread],
	);

However, getOneTransactionThreadReportID immediately rejects reports whose type is not IOU, EXPENSE, or INVOICE:

App/src/libs/ReportActionsUtils.ts

Lines 1847 to 1848 in 4195ea3

	if (report?.type !== CONST.REPORT.TYPE.IOU && report?.type !== CONST.REPORT.TYPE.EXPENSE && report?.type !== CONST.REPORT.TYPE.INVOICE) {
	return;

Since the transaction thread has type CHAT, the function returns undefined. This means getCombinedReportActions at line 244 receives null as the transaction thread ID and returns only the transaction thread's own actions — without merging the parent IOU report's actions:

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

Lines 243 to 246 in 4195ea3

	const reportActions = useMemo(
	() => (reportActionsToDisplay ? getCombinedReportActions(reportActionsToDisplay, transactionThreadReportID ?? null, transactionThreadReportActions ?? []) : []),
	[reportActionsToDisplay, transactionThreadReportActions, transactionThreadReportID],
	);

The "Submitted" system message is a SUBMITTED report action stored in the parent IOU report, not in the transaction thread. So it is never included in the displayed action list when viewing the thread directly.

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

In ReportActionsView, when the current report is a transaction thread, detect whether it belongs to a one-transaction parent IOU report by checking from the parent's perspective. If so, load the parent report's actions and merge them using getCombinedReportActions — passing the parent's actions as the base and the current thread's actions as the child. This ensures system messages like "Submitted" from the parent IOU report appear in the combined view, matching the behavior when the user navigates to the parent IOU report directly.

The check uses the existing chatReport (which for a transaction thread is the parent IOU report via chatReportID), loads its report actions, and calls getOneTransactionThreadReportID from the parent's perspective to confirm this thread is the sole transaction thread.

What alternative solutions did you explore? (Optional)

1. Change getOriginalReportID to return the parent IOU report ID — this would make the copied link point to the parent report. However, the reportActionID in the link belongs to the transaction thread, and the server's openReport for the parent wouldn't return actions centered around an action from a different report. The pagination would break.

2. Redirect from the transaction thread to the parent IOU report in ReportFetchHandler — this would navigate the user to the parent, showing the combined view. But again, the reportActionID from the thread wouldn't be found in the parent's paginated actions, causing scroll-to to fail.

The chosen approach (merging parent actions in ReportActionsView when viewing a one-transaction thread) preserves the correct pagination/scroll behavior for the linked message while also showing the parent's system messages.

Compare link: main...wildan-m:App:wildan/86919-iou-message-not-scrolled

[abbasifaizan70]

Proposal

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

When navigating to an expense details thread via a copied message link, the "Submitted" system message does not appear and the linked message may not be scrolled to correctly.

What is the root cause of that problem?

The copied link is generated with originalReportID, which can resolve to a transaction-thread report ID in one-transaction expense flows. Opening that URL lands in the thread route first instead of the displayed parent expense context.

App/src/pages/inbox/report/ContextMenu/ContextMenuActions.tsx

Lines 1102 to 1108 in e6d82ef

	onPress: (closePopover, {reportAction, originalReportID}) => {
	getEnvironmentURL().then((environmentURL) => {
	const reportActionID = reportAction?.reportActionID;
	Clipboard.setString(`${environmentURL}/r/${originalReportID}/${reportActionID}`);
	});
	hideContextMenu(true, ReportActionComposeFocusManager.focus);
	},

After navigation, linked-message pagination requires the target action to exist in the selected report action collection. When the wrong report context is opened first, the linked action is often not yet present there on first load, so the list cannot anchor to it.

App/src/libs/PaginationUtils.ts

Lines 215 to 221 in e6d82ef

	// If we found an item with the resource id, we want link to the specific page with the item
	if (id) {
	// If we are searching for an item with a specific resource id and
	// we are linking to an action that doesn't exist in Onyx, return an empty array
	if (!didFindItem) {
	return {data: [], hasNextPage: false, hasPreviousPage: false, resourceItem};
	}

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

Generate the copied link with the displayed report ID so one-transaction expense links always open in the same parent expense context that contains the full action timeline.

App/src/pages/inbox/report/ContextMenu/ContextMenuActions.tsx

Lines 1102 to 1108 in e6d82ef

	onPress: (closePopover, {reportAction, originalReportID}) => {
	getEnvironmentURL().then((environmentURL) => {
	const reportActionID = reportAction?.reportActionID;
	Clipboard.setString(`${environmentURL}/r/${originalReportID}/${reportActionID}`);
	});
	hideContextMenu(true, ReportActionComposeFocusManager.focus);
	},

onPress: (closePopover, {reportAction, originalReportID}) => {
    getEnvironmentURL().then((environmentURL) => {
        const reportActionID = reportAction?.reportActionID;
        const reportID = originalReportID ? getDisplayedReportID(originalReportID) : originalReportID;
        Clipboard.setString(`${environmentURL}/r/${reportID}/${reportActionID}`);
    });
    hideContextMenu(true, ReportActionComposeFocusManager.focus);
},

What alternative solutions did you explore? (Optional)

None