[$250] Expense - Second created in Reports expense is not highlighted

[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: 9.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: #85248 step 5
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: Money Requests

Action Performed:

1. Sign in to ND app
2. Navigate to Reports tab - Expenses
3. Tap FAB - Create expense - create a manual expense to the workspace or other user - verify it's highlighted in the list
4. Not leaving Reports tab, repeat step 3, using "Create expense" in the FAB menu or Quick action button

Expected Result:

Newly created expense is highlighted in the Reports/ Expenses

Actual Result:

The second created expense is not highlighted n the Reports/ Expenses

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: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034624589043538275
• Upwork Job ID: 2034624589043538275
• Last Price Increase: 2026-04-16

[MelvinBot]

Proposal

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

When a user creates a second expense from the Reports > Expenses tab (via the FAB or Quick Action button) without leaving the tab, the newly created expense is not highlighted in the list. The first expense created highlights correctly, but subsequent ones do not.

What is the root cause of that problem?

The Search/Expenses list highlighting is managed by useSearchHighlightAndScroll. There are two paths that trigger highlighting:

1. Manual highlight path: handleNavigateAfterExpenseCreate (in IOU/index.ts:1171) calls mergeTransactionIdsHighlightOnSearchRoute to write the new transaction ID to ONYXKEYS.TRANSACTION_IDS_HIGHLIGHT_ON_SEARCH_ROUTE. The hook reads this via useOnyx and uses it to bypass the auto-detect guards.

2. Auto-detect path: The effect at line 78 detects new transactions in the Onyx collection, triggers a search API call, and the "Detect new items" effect at line 181 identifies new transaction IDs in the search results and sets newSearchResultKeys to trigger the highlight animation.

The root cause is a focus/timing race condition in useSearchHighlightAndScroll. When the user creates the second expense:

1. The expense creation modal opens on top of the Search page, causing the page to become unfocused (isFocused = false from useIsFocused()).
2. The new transaction is added to Onyx optimistically, and mergeTransactionIdsHighlightOnSearchRoute sets {[txn2ID]: true}.
3. The auto-detect effect at line 78 runs and sees !isFocused at line 103, so it defers the search by setting hasPendingSearchRef.current = true and returns.
4. Meanwhile, previousTransactions (from usePrevious) catches up — its useEffect updates the ref to include the new transaction during subsequent renders while the page is unfocused.
5. When the expense creation completes and the modal dismisses, the page regains focus.
6. The effect re-runs due to isFocused changing. hasPendingSearchRef.current is true, so a search IS triggered. But at line 129: hasNewItemsRef.current = transactionsIDs.length > previousTransactionIDsLocal.length evaluates to false because previousTransactions already caught up (both have the same length).
7. When search results arrive, the "Detect new items" effect at line 181 fires. The manual highlight path at line 210 checks manualHighlightTransactionIDs.has(id), which should include txn2ID from transactionIDsToHighlight. However, the filter at line 209 operates on currentTransactionIDs extracted from searchResults.data. If the "Detect new items" effect fires due to the transactionIDsToHighlight dependency change before the search API returns new results, currentTransactionIDs won't include the second transaction, and newTransactionIDs will be empty.

The first expense works because the page is either already focused when the transaction is created (or becomes focused at the right time), so previousTransactions hasn't caught up yet, hasNewItemsRef.current is correctly true, and both the auto-detect and manual highlight paths function properly.

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

The fix should ensure the manual highlight path works reliably even when the auto-detect path's hasNewItemsRef is stale. Two approaches:

Approach A (Recommended): In the "Detect new items" effect at line 181, when manualHighlightTransactionIDs contains IDs that are NOT yet in currentTransactionIDs (i.e., the search results haven't been refreshed yet), don't process them — but also don't consider them "done". Instead, skip them and let them be processed on the next effect execution when search results DO include them. Currently the logic already does this implicitly (the filter at line 209 only includes IDs that are in currentTransactionIDs), but we need to ensure the effect re-fires when search results arrive. This should already happen since searchResults?.data is a dependency. The issue may be that previousSearchResults catches up between firings, causing the effect to not detect the new items. Adding transactionIDsToHighlight IDs that haven't been processed to a ref that persists across renders could help ensure they're eventually processed.

Approach B: Move the hasNewItemsRef.current computation to account for the focus/unfocus cycle. Instead of comparing lengths synchronously in the effect body, store the "pre-unfocus" transaction count and compare against the post-focus count. This would correctly detect that the transaction count grew even if previousTransactions caught up during the unfocused period.

What alternative solutions did you explore? (Optional)

An alternative would be to not defer the search trigger when the page is unfocused (remove the !isFocused guard at line 103). However, this guard exists for performance reasons (avoid unnecessary search API calls when the results won't be visible), so removing it could have side effects.

Another alternative would be to have handleNavigateAfterExpenseCreate delay its mergeTransactionIdsHighlightOnSearchRoute call until after the navigation completes (when the search page is focused), but this would require restructuring the async flow and could introduce other timing issues.

---

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

[melvin-bot]

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

[twilight2294]

Proposal

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

When a user creates a second expense from the Reports > Expenses tab, the newly created expense is not highlighted in the list. The first expense highlights correctly, but subsequent ones do not.

What is the root cause of that problem?

The highlight state is managed via an Onyx key (TRANSACTION_IDS_HIGHLIGHT_ON_SEARCH_ROUTE). When an expense is created, handleNavigateAfterExpenseCreate() in index calls mergeTransactionIdsHighlightOnSearchRoute() to mark the new transaction for highlighting. The hook useSearchHighlightAndScroll has a cleanup effect that runs on unmount and calls mergeTransactionIdsHighlightOnSearchRoute(queryJSON.type, null), which clears all pending highlights for that type.

The race condition occurs during the second expense creation. At line 1171, the highlight is set for the new transaction ID. Then at line 1196, Navigation.navigate(..., {forceReplace: true}) is called on narrow layout (mobile), which unmounts the existing Search component. The cleanup effect fires and writes null to Onyx, overwriting the highlight that was just set moments earlier. When the new Search component mounts, the highlight data is gone.

The first expense works because there is no existing Search component to unmount — the user navigates there fresh, so no cleanup effect runs. This also explains why it's mobile-only: forceReplace: true is only used on narrow layout (line 1196), while wide layout uses revealRouteBeforeDismissingModal (line 1198), which doesn't cause a full unmount/remount cycle.

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

Move the mergeTransactionIdsHighlightOnSearchRoute call in handleNavigateAfterExpenseCreate() to after the navigation call, so it runs after the old component's cleanup effect has already cleared the state. In index, the highlight merge currently happens at line 1171, before the navigation at lines 1194–1198. It should be moved inside the .then() callback, after the navigate:

Navigation.isNavigationReady().then(() => {
    if (getIsNarrowLayout()) {
        Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: true});
    } else {
        Navigation.revealRouteBeforeDismissingModal(ROUTES.SEARCH_ROOT.getRoute({query: queryString}));
    }
    // Set highlight AFTER navigation so the old component's cleanup runs first
    mergeTransactionIdsHighlightOnSearchRoute(type, {[transactionID]: true});
});

This ensures the Onyx writes happen in the correct order: cleanup clears the old state first, then the new highlight is written, so the newly mounted Search component picks it up.

What alternative solutions did you explore? (Optional)

The existing proposal identifies the auto-detect path's hasNewItemsRef staleness as the root cause. While that is a contributing factor in some flows, the fundamental issue is simpler: the cleanup effect at useSearchHighlightAndScroll directly overwrites the highlight state that was just set. My fix is a single-line move in one file rather than adding new refs or changing the detection logic in the hook, and it addresses the root ordering issue directly.

An alternative would be to guard the cleanup effect (e.g., wrapping it in requestAnimationFrame), but that introduces timing sensitivity. Moving the merge call after navigation is deterministic and minimal.

[czarflix]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @czarflix Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[abbasifaizan70]

Proposal

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

In Reports > Expenses on mobile, when a user creates an expense and stays on the same tab, the first newly created expense is highlighted, but creating another expense immediately after does not highlight the second one.

What is the root cause of that problem?

The highlight animation is driven by shouldHighlight, and the animation hook only starts when that value transitions to true.
When the same report row receives another new expense quickly, the row can remain in highlighted state, so the second event does not create a new false -> true transition and the animation does not retrigger.

App/src/hooks/useAnimatedHighlightStyle/index.ts

Lines 92 to 101 in d05d2a0

	React.useEffect(() => {
	if (!shouldHighlight || startHighlight) {
	return;
	}
	setStartHighlight(true);
	// We only need to add shouldHighlight as a dependency and adding startHighlight as deps will cause a loop because
	// if shouldHighlight stays at true the above early return will not be executed and this useEffect will be run
	// as long as shouldHighlight is true as we set startHighlight to false in the below useEffect.
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldHighlight]);

App/src/components/Search/index.tsx

Lines 1170 to 1194 in d05d2a0

	const sortedData = useMemo(
	() =>
	getSortedSections(type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy).map((item) => {
	const baseKey = isChat
	? `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${(item as ReportActionListItemType).reportActionID}`
	: `${ONYXKEYS.COLLECTION.TRANSACTION}${(item as TransactionListItemType).transactionID}`;
	const isBaseKeyMatch = !!newSearchResultKeys?.has(baseKey);
	const isAnyTransactionMatch =
	!isChat &&
	(item as TransactionGroupListItemType)?.transactions?.some((transaction) => {
	const transactionKey = `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`;
	return !!newSearchResultKeys?.has(transactionKey);
	});
	const shouldAnimateInHighlight = isBaseKeyMatch || isAnyTransactionMatch;
	if (item.shouldAnimateInHighlight === shouldAnimateInHighlight && item.hash === hash) {
	return item;
	}
	return {...item, shouldAnimateInHighlight, hash};
	}),
	[type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy, isChat, newSearchResultKeys, hash],

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

1. Extend list item shape with a retrigger token so repeated highlight events on the same row can be distinguished.

App/src/components/SelectionListWithSections/types.ts

Lines 240 to 241 in d05d2a0

	/** Determines whether the newly added item should animate in / highlight */
	shouldAnimateInHighlight?: boolean;

type ListItem<K extends string | number = string> = {
    // existing props...
    shouldAnimateInHighlight?: boolean;

    /** A value used to retrigger highlight animation for repeated events */
    highlightAnimationTrigger?: string;
};

2. In Search mapping, compute a stable trigger from newSearchResultKeys, attach it to highlighted items, and include it in the item reuse guard.

App/src/components/Search/index.tsx

Lines 1170 to 1194 in d05d2a0

	const sortedData = useMemo(
	() =>
	getSortedSections(type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy).map((item) => {
	const baseKey = isChat
	? `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${(item as ReportActionListItemType).reportActionID}`
	: `${ONYXKEYS.COLLECTION.TRANSACTION}${(item as TransactionListItemType).transactionID}`;
	const isBaseKeyMatch = !!newSearchResultKeys?.has(baseKey);
	const isAnyTransactionMatch =
	!isChat &&
	(item as TransactionGroupListItemType)?.transactions?.some((transaction) => {
	const transactionKey = `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`;
	return !!newSearchResultKeys?.has(transactionKey);
	});
	const shouldAnimateInHighlight = isBaseKeyMatch || isAnyTransactionMatch;
	if (item.shouldAnimateInHighlight === shouldAnimateInHighlight && item.hash === hash) {
	return item;
	}
	return {...item, shouldAnimateInHighlight, hash};
	}),
	[type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy, isChat, newSearchResultKeys, hash],

const highlightAnimationTrigger = useMemo(() => {
    if (!newSearchResultKeys || newSearchResultKeys.size === 0) {
        return undefined;
    }

    return [...newSearchResultKeys].sort().join('|');
}, [newSearchResultKeys]);

const sortedData = useMemo(
    () =>
        getSortedSections(type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy).map((item) => {
            const baseKey = isChat
                ? `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${(item as ReportActionListItemType).reportActionID}`
                : `${ONYXKEYS.COLLECTION.TRANSACTION}${(item as TransactionListItemType).transactionID}`;

            const isBaseKeyMatch = !!newSearchResultKeys?.has(baseKey);
            const isAnyTransactionMatch =
                !isChat &&
                (item as TransactionGroupListItemType)?.transactions?.some((transaction) => {
                    const transactionKey = `${ONYXKEYS.COLLECTION.TRANSACTION}${transaction.transactionID}`;
                    return !!newSearchResultKeys?.has(transactionKey);
                });

            const shouldAnimateInHighlight = isBaseKeyMatch || isAnyTransactionMatch;
            const nextHighlightAnimationTrigger = shouldAnimateInHighlight ? highlightAnimationTrigger : undefined;

            if (
                item.shouldAnimateInHighlight === shouldAnimateInHighlight &&
                item.highlightAnimationTrigger === nextHighlightAnimationTrigger &&
                item.hash === hash
            ) {
                return item;
            }

            return {...item, shouldAnimateInHighlight, highlightAnimationTrigger: nextHighlightAnimationTrigger, hash};
        }),
    [type, status, filteredData, localeCompare, translate, sortBy, sortOrder, validGroupBy, isChat, newSearchResultKeys, highlightAnimationTrigger, hash],
);

3. Update the highlight hook to accept a trigger dependency and retrun animation when the trigger changes.

App/src/hooks/useAnimatedHighlightStyle/index.ts

Lines 33 to 38 in d05d2a0

	/** Whether the item should be highlighted */
	shouldHighlight: boolean;
	/** Whether it should return height and border radius styles */
	shouldApplyOtherStyles?: boolean;

App/src/hooks/useAnimatedHighlightStyle/index.ts

Lines 57 to 71 in d05d2a0

	export default function useAnimatedHighlightStyle({
	borderRadius,
	shouldHighlight,
	itemEnterDelay = CONST.ANIMATED_HIGHLIGHT_ENTRY_DELAY,
	itemEnterDuration = CONST.ANIMATED_HIGHLIGHT_ENTRY_DURATION,
	highlightStartDelay = CONST.ANIMATED_HIGHLIGHT_START_DELAY,
	highlightStartDuration = CONST.ANIMATED_HIGHLIGHT_START_DURATION,
	highlightEndDelay = CONST.ANIMATED_HIGHLIGHT_END_DELAY,
	highlightEndDuration = CONST.ANIMATED_HIGHLIGHT_END_DURATION,
	height,
	highlightColor,
	backgroundColor,
	shouldApplyOtherStyles = true,
	skipInitialFade = false,
	}: Props) {

App/src/hooks/useAnimatedHighlightStyle/index.ts

Lines 92 to 101 in d05d2a0

	React.useEffect(() => {
	if (!shouldHighlight || startHighlight) {
	return;
	}
	setStartHighlight(true);
	// We only need to add shouldHighlight as a dependency and adding startHighlight as deps will cause a loop because
	// if shouldHighlight stays at true the above early return will not be executed and this useEffect will be run
	// as long as shouldHighlight is true as we set startHighlight to false in the below useEffect.
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [shouldHighlight]);

type Props = {
    shouldHighlight: boolean;
    shouldApplyOtherStyles?: boolean;

    /** Optional value that retriggers animation when changed while highlighted */
    highlightTrigger?: string;
    // existing props...
};

export default function useAnimatedHighlightStyle({
    shouldHighlight,
    shouldApplyOtherStyles = true,
    highlightTrigger,
    // existing params...
}: Props) {
    React.useEffect(() => {
        if (!shouldHighlight || startHighlight) {
            return;
        }
        setStartHighlight(true);
    }, [shouldHighlight, highlightTrigger]);

    // existing animation logic...
}

4. Pass the new trigger from the expense report list item into the animation hook.

App/src/components/SelectionListWithSections/Search/ExpenseReportListItem.tsx

Lines 183 to 188 in d05d2a0

	const animatedHighlightStyle = useAnimatedHighlightStyle({
	borderRadius: variables.componentBorderRadius,
	shouldHighlight: item?.shouldAnimateInHighlight ?? false,
	highlightColor: theme.messageHighlightBG,
	backgroundColor: theme.highlightBG,
	});

const animatedHighlightStyle = useAnimatedHighlightStyle({
    borderRadius: variables.componentBorderRadius,
    shouldHighlight: item?.shouldAnimateInHighlight ?? false,
    highlightTrigger: item?.highlightAnimationTrigger,
    highlightColor: theme.messageHighlightBG,
    backgroundColor: theme.highlightBG,
});

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Expense search: create expense A, then create expense B without leaving Reports > Expenses; verify B is included in newSearchResultKeys and highlight retriggers.
2. Expense report grouping row: when the same report receives consecutive new transactions, highlight animation retriggers for each event.
3. Regression: when no new result keys are present, rows should not re-render for highlight-only props.
4. Existing manual highlight flow (transactionIdsHighlightOnSearchRoute) should still work and clear highlight flags after timeout.

[gps949]

Proposal

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

When a user creates a second expense from the Reports > Expenses tab without leaving the screen, the newly created expense does not get highlighted. Only the first expense creation triggers the highlight animation.

What is the root cause of that problem?

The issue is in useAnimatedHighlightStyle hook (src/hooks/useAnimatedHighlightStyle/index.ts). The detect effect (line 92-100) depends only on [shouldHighlight]:

React.useEffect(() => {
    if (!shouldHighlight || startHighlight) {
        return;
    }
    setStartHighlight(true);
}, [shouldHighlight]);

When expenses are grouped under the same report in Search results (ExpenseReportListItem), the same component instance handles both highlights. After the first highlight completes, startHighlight resets to false via the animation callback. When the second expense is created:

1. newSearchResultKeys in useSearchHighlightAndScroll is cleared (→ shouldHighlight: false) then set again for the new transaction (→ shouldHighlight: true)
2. However, React may batch these state transitions within the same render cycle, meaning the effect on [shouldHighlight] doesn't re-fire because it never observes the intermediate false value

The hook has no mechanism to distinguish between "first highlight" and "second highlight" — it only reacts to the shouldHighlight boolean toggling, which is insufficient when the same component needs to animate again for a different transaction.

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

Add a highlightTrigger prop to useAnimatedHighlightStyle that changes whenever a NEW highlight is needed, even if shouldHighlight remains true:

1. src/hooks/useAnimatedHighlightStyle/index.ts: Add optional highlightTrigger?: string to Props. Include it in the detect effect's dependency array:

   React.useEffect(() => {
       if (!shouldHighlight || startHighlight) {
           return;
       }
       setStartHighlight(true);
   }, [shouldHighlight, highlightTrigger]);

2. src/components/Search/index.tsx: Compute a highlightAnimationTrigger string from newSearchResultKeys (e.g. [...keys].sort().join('|')). Include it in each item's data passed to list items via sortedData.

3. List item components (ExpenseReportListItem.tsx, TransactionListItem.tsx, TransactionGroupListItem.tsx): Pass item.highlightAnimationTrigger as highlightTrigger to useAnimatedHighlightStyle.

4. Types: Add highlightAnimationTrigger?: string to the relevant item types.

Each new highlight produces a unique trigger string (since newSearchResultKeys contains different transaction IDs), forcing the effect to re-fire regardless of React's batching behavior.

What alternative solutions did you explore? (Optional)

• Using a key prop to force remount of the list item — rejected because it breaks scroll position and other state
• Using useRef with a counter instead of string trigger — works but less debuggable
• Resetting startHighlight to false with a timeout before the second highlight — fragile and race-condition prone