[$250] Expense -Scan expense appears in the first position in the carousel position after smartscan

[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: v9.3.81-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91467
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.5
App Component: Money Requests

Action Performed:

1. Go to https://staging.new.expensify.com
2. Go to the workspace chat
3. Create a manual expense
4. In the same report, create a scan expense
5. Wait for the smartscan to finish

Expected Result:

The scanned expense should remain in the same position in the carousel preview after SmartScan completes.

Actual Result:

Scan expense appears in the first position in the carousel position after smartscan

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7162771_1779721395152.Recording__2264.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7162771

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058935241083710702
• Upwork Job ID: 2058935241083710702
• Last Price Increase: 2026-05-25

[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/ede0ac8d7903eac7c518727af2af28babddb49ae5226643470cf8ae7c2b9cdba

[MelvinBot]

Proposal

What is the root cause of that problem?

The carousel sorts transactions with RBR (Red Brick Road) violations first, then by created date ascending. While SmartScan is in progress, isReceiptBeingScanned() returns true, which suppresses the hasMissingSmartscanFields() check — so the scan transaction has no RBR during scanning and stays in its original position.

When SmartScan completes, receipt.state becomes SCANCOMPLETE, isReceiptBeingScanned() flips to false, and if any required fields are still missing (amount, merchant, etc.), hasMissingSmartscanFields() now returns true → the transaction gains RBR status. The compareByRBR() function in the carousel sort then pushes it to position 0.

A secondary factor: both same-day transactions share the same created date (yyyy-MM-dd with no time component, set at MoneyRequest.ts:883), making the date tiebreaker unstable. The server may also update created to the receipt date after SmartScan, further disrupting order.

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

The carousel sort should preserve the original insertion order when RBR status changes. Instead of only tiebreaking by created date (which is identical for same-day transactions), add a secondary tiebreaker using a stable, creation-order-preserving key — such as transactionID (which is monotonically increasing) — so that RBR status changes don't cause position jumps for transactions created on the same day.

In MoneyRequestReportPreviewContent.tsx, after the localeCompare(getCreated(a), getCreated(b)) tiebreaker, add a final tiebreaker comparing transactionID strings to maintain stable ordering. The same change should be applied to the sort in MoneyRequestReportTransactionList.tsx for consistency.

Additionally, consider whether RBR-first sorting should apply to the carousel preview at all — the carousel is a visual preview, not an action queue, so reordering it based on violation status may be confusing to users regardless.

What alternative solutions did you explore?

1. Suppress RBR sorting entirely in the carousel — simpler but changes the existing design intent of surfacing violations prominently. Could be the right call if product decides violations shouldn't drive carousel order.
2. Use created with full timestamp instead of date-only — would help with the date tiebreaker instability but doesn't solve the RBR-driven reorder, which is the primary cause.

Investigation details

Sorting logic (carousel): MoneyRequestReportPreviewContent.tsx:356-368 — sorts by RBR first via compareByRBR, then by getCreated() ascending.

Sorting logic (transaction list): MoneyRequestReportTransactionList.tsx:296-316 — same RBR-first pattern with date tiebreaker.

RBR comparison: TransactionPreviewUtils.ts:543-561 — returns -1 for RBR transactions, pushing them to front.

SmartScan guard: TransactionUtils/index.ts:1568-1569 — hasMissingSmartscanFields is suppressed while isReceiptBeingScanned() is true, then activates after scan completes.

Created date format: MoneyRequest.ts:883 — format(new Date(), 'yyyy-MM-dd') produces date-only strings, making same-day tiebreakers return 0.

---

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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 15:37:36 UTC.

Proposal

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

When a workspace chat has a manual expense and then a scanned expense, the scan slides over to the first position in the report preview carousel as soon as SmartScan finishes — even though nothing else about its order should change.

What is the root cause of that problem?

PR #91467 added a date-based tiebreaker to the carousel sort (oldest first) on top of the RBR comparison. The tiebreaker is localeCompare(getCreated(a), getCreated(b)), and getCreated returns transaction.modifiedCreated || transaction.created. While SmartScan is running, the scan transaction's created is DateUtils.getDBTime() (i.e. "now"), so it sorts after the older manual expense. Once SmartScan completes, the backend populates modifiedCreated with the actual receipt date — which is almost always earlier than the manual expense — so getCreated flips to that older value and the tiebreaker yanks the scan to the front of the carousel.

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

Lines 360 to 367 in 668b0df

	const sorted = [...transactions].sort((a, b) => {
	const rbrComparison = compareByRBR(a, b, transactionViolations, currentUserDetails?.login ?? '', currentUserDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, iouReport, policy);
	if (rbrComparison !== 0) {
	return rbrComparison;
	}
	// Tiebreak by date (ascending — oldest first) so position is stable across RBR state changes
	return localeCompare(getCreated(a), getCreated(b));
	});

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

The tiebreaker needs a key that doesn't mutate when SmartScan completes. transaction.inserted is set once by the backend when the transaction is created and never changes afterward, which is exactly the "stable insertion order" the PR #91467 fix was reaching for. We should update the tiebreaker in carouselTransactions inside MoneyRequestReportPreviewContent.tsx to compare by a.inserted / b.inserted first, and only fall back to getCreated when inserted is missing (purely optimistic transactions that haven't synced yet). That keeps the original PR's intent (stable order across RBR state changes) while no longer reshuffling when SmartScan rewrites modifiedCreated.

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

Lines 365 to 366 in 668b0df

	// Tiebreak by date (ascending — oldest first) so position is stable across RBR state changes
	return localeCompare(getCreated(a), getCreated(b));

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The expense carousel in the report preview sorts transactions by RBR status first, then breaks ties with a date comparison. That date tiebreaker was added in PR #91467 precisely to keep positions stable across RBR state changes:

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

Lines 360 to 367 in c3dba01

	const sorted = [...transactions].sort((a, b) => {
	const rbrComparison = compareByRBR(a, b, transactionViolations, currentUserDetails?.login ?? '', currentUserDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, iouReport, policy);
	if (rbrComparison !== 0) {
	return rbrComparison;
	}
	// Tiebreak by date (ascending — oldest first) so position is stable across RBR state changes
	return localeCompare(getCreated(a), getCreated(b));
	});

The tiebreaker key is getCreated(), which returns the expense date (modifiedCreated || created):

App/src/libs/TransactionUtils/index.ts

Lines 1392 to 1394 in c3dba01

	function getCreated(transaction: OnyxInputOrEntry<Transaction>): string {
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	return transaction?.modifiedCreated ? transaction.modifiedCreated : transaction?.created || '';

The problem is that this key is mutable for scan expenses. The optimistic created is a date-only string (yyyy-MM-dd), set in initMoneyRequest:

App/src/libs/actions/IOU/MoneyRequest.ts

Line 883 in c3dba01

* @param iouRequestType one of manual/scan/distance

Tracing the flow (both expenses created the same day):

1. Manual expense and scan expense are both created today, so each has the identical created = '2026-05-25'. Neither has an RBR, so compareByRBR returns 0 and the tiebreaker localeCompare('2026-05-25', '2026-05-25') is also 0 — a tie. The scan expense holds 2nd position only because the input array is in insertion order and the sort is stable.
2. SmartScan completes and the backend overwrites the scan transaction's created/modifiedCreated with the receipt's real date, which is almost always a past date (e.g. 2026-05-22).
3. Re-sort now sees getCreated(scan) = '2026-05-22' < getCreated(manual) = '2026-05-25', so the oldest-first tiebreaker is no longer a tie and moves the scan expense to the first position.

So the key chosen to make the position stable is both (a) the one value SmartScan is guaranteed to rewrite, and (b) a same-day tie that leaves ordering to fragile array order — exactly defeating its own purpose for scan expenses.

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

Tiebreak by the transaction's insertion order (inserted) instead of the mutable expense date. inserted is a full DB timestamp stamped once at creation in buildOptimisticTransaction (L552) and is never touched by SmartScan. It fixes both failure modes above: it doesn't change when the receipt date arrives, and because it carries millisecond precision it is a genuine deterministic tiebreaker even when two same-day expenses share a date-only created. This is the same immutable creation-order key already used as the stable tiebreaker in getAllSortedTransactions (L2712).

-            // Tiebreak by date (ascending — oldest first) so position is stable across RBR state changes
-            return localeCompare(getCreated(a), getCreated(b));
+            // Tiebreak by insertion order (ascending — oldest first) so position is stable across both RBR
+            // state changes and SmartScan, which overwrites `created`/`modifiedCreated` with the receipt date
+            return localeCompare(a.inserted ?? getCreated(a), b.inserted ?? getCreated(b));

getCreated is kept as a fallback for any transaction missing inserted, so the import stays used and no other change is required.

What alternative solutions did you explore? (Optional)

• Freeze the order with a memoized index map / ref keyed by transactionID on first render — adds state, doesn't survive remount or reload, and breaks when transactions are added/removed. inserted gives the same stability for free.
• Tiebreak by the IOU report action's created timestamp — also stable, but requires plumbing report actions into the sort; inserted already lives on the transaction object and is the established pattern, so it's the smaller, more consistent change.

[melvin-bot]

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

[wildan-m]

Proposal

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

In a workspace chat report that contains more than one expense, the expense carousel preview reorders itself when a scan expense finishes SmartScan. After creating a manual expense followed by a scan expense, the scan expense correctly sits in the second position while it is still scanning, but once SmartScan completes it jumps to the first position instead of staying where it was.

What is the root cause of that problem?

The carousel builds its ordered list in MoneyRequestReportPreviewContent. Transactions are sorted first by Red Brick Road status, and ties are broken by date in ascending order:

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

Lines 356 to 369 in 79426b2

	const carouselTransactions = useMemo(() => {
	if (shouldShowAccessPlaceHolder) {
	return [];
	}
	const sorted = [...transactions].sort((a, b) => {
	const rbrComparison = compareByRBR(a, b, transactionViolations, currentUserDetails?.login ?? '', currentUserDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, iouReport, policy);
	if (rbrComparison !== 0) {
	return rbrComparison;
	}
	// Tiebreak by date (ascending — oldest first) so position is stable across RBR state changes
	return localeCompare(getCreated(a), getCreated(b));
	});
	return sorted.slice(0, 11);
	}, [shouldShowAccessPlaceHolder, transactions, transactionViolations, currentUserDetails?.login, currentUserDetails?.accountID, iouReport, policy, localeCompare]);

The tiebreaker calls getCreated, which returns modifiedCreated whenever it is present and only falls back to the raw created field otherwise:

App/src/libs/TransactionUtils/index.ts

Lines 1392 to 1395 in 79426b2

	function getCreated(transaction: OnyxInputOrEntry<Transaction>): string {
	// eslint-disable-next-line @typescript-eslint/prefer-nullish-coalescing
	return transaction?.modifiedCreated ? transaction.modifiedCreated : transaction?.created || '';
	}

modifiedCreated holds the displayed/edited date, not the original creation order. When a scan expense is first created it has no modifiedCreated, so the tiebreaker uses its raw created timestamp (which is later than the manual expense created just before it) and the scan expense correctly stays in second place. When SmartScan completes, the date detected from the receipt is written into modifiedCreated. That date is typically older than the day the expense was created, so getCreated now returns the older receipt date, the ascending date tiebreaker moves the scan expense ahead of the manual expense, and it jumps to the first position.

Both expenses are clean after scanning (no violations), so compareByRBR returns 0 and the date tiebreaker is what actually decides the order — which is why the reorder is observable.

This is inconsistent with how the rest of the app orders a report's transactions. getAllSortedTransactions sorts by the immutable raw created field and uses inserted as the tiebreaker, never modifiedCreated:

App/src/libs/TransactionUtils/index.ts

Lines 2702 to 2713 in 79426b2

	function getAllSortedTransactions(iouReportID?: string): Array<OnyxEntry<Transaction>> {
	return getReportTransactions(iouReportID).sort((transA, transB) => {
	if (transA.created < transB.created) {
	return -1;
	}
	if (transA.created > transB.created) {
	return 1;
	}
	return (transA.inserted ?? '') < (transB.inserted ?? '') ? -1 : 1;
	});

Because that canonical sort ignores modifiedCreated, the report's transaction list does not reorder after SmartScan — only the carousel does, since the carousel is the only place that ties on the mutable display date.

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

Change the carousel tiebreaker in MoneyRequestReportPreviewContent so it no longer ties on the mutable display date. Instead of comparing getCreated(a) and getCreated(b), break ties on the immutable creation order, matching getAllSortedTransactions: compare the raw created field first and fall back to inserted when the raw created values are equal.

The raw created and inserted fields are set once when the transaction is built and are not changed when SmartScan writes the detected receipt date (which lands in modifiedCreated) or when a user edits the date. As a result the carousel position stays stable across SmartScan completion, while still preserving the existing behavior of putting Red Brick Road expenses first and keeping a deterministic, stable order for the original intent of the previous fix (stability across RBR state changes).

The getCreated import that was added solely for this tiebreaker can be removed if it is no longer used elsewhere in the file.

What alternative solutions did you explore? (Optional)

Reusing getAllSortedTransactions directly to produce the carousel list and then applying only the RBR re-ordering on top was considered, but that is a larger refactor than necessary; switching the existing inline tiebreaker to the immutable creation order is the minimal, targeted fix and keeps the RBR-first behavior intact.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

carouselTransactions in MoneyRequestReportPreviewContent re-sorts transactions on every change using compareByRBR, which moves transactions with RBR ahead of those without:

https://github.com/Expensify/App/blob/main/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx#L359-L367

const carouselTransactions = useMemo(() => {
    if (shouldShowAccessPlaceHolder) {
        return [];
    }
    const sorted = [...transactions].sort((a, b) =>
        compareByRBR(a, b, transactionViolations, currentUserDetails?.login ?? '', currentUserDetails?.accountID ?? CONST.DEFAULT_NUMBER_ID, iouReport, policy),
    );
    return sorted.slice(0, 11);
}, [shouldShowAccessPlaceHolder, transactions, transactionViolations, currentUserDetails?.login, currentUserDetails?.accountID, iouReport, policy]);

The repro maps directly onto this:

1. Manual expense created first — no RBR. Carousel order: [manual].
2. Scan expense added — during smartscan, the transaction is missing merchant/amount, so hasMissingSmartscanFields(transaction, iouReport) at https://github.com/Expensify/App/blob/main/src/libs/TransactionPreviewUtils.ts#L516-L518 returns true, transactionHasRBR returns true, and compareByRBR returns -1 for the scan. Sort moves it ahead: [scan, manual].
3. Smartscan completes — fields populate, hasMissingSmartscanFields flips to false, scan no longer has RBR.
4. useMemo re-runs (deps changed because transactions and transactionViolations updated). Both transactions now have RBR = false, so compareByRBR returns 0 for the pair.

Array.prototype.sort is stable in modern V8, so equal-comparing items preserve relative order — but the relative order being preserved is the current [scan, manual] order from step 2, not the original [manual, scan] insertion order. The sort once-promoted the scan, the equality on re-sort holds it in front.

The video confirms this: the scan stays in position 0 after smartscan completes, ahead of the manual expense that was actually created first.

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

Make the sort a true partial ordering with a stable tiebreaker on creation time. When neither transaction has RBR (or both do), fall back to created ascending so the natural chronological order is restored:

  function compareByRBR(
      a: OnyxTypes.Transaction,
      b: OnyxTypes.Transaction,
      violations: Record<string, OnyxTypes.TransactionViolations | undefined> | undefined,
      currentUserEmail: string,
      currentUserAccountID: number,
      iouReport: OnyxEntry<OnyxTypes.Report>,
      policy: OnyxEntry<OnyxTypes.Policy>,
      reportActions?: OnyxTypes.ReportActions,
  ): number {
      const aViolations = violations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${a.transactionID}`] ?? [];
      const bViolations = violations?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${b.transactionID}`] ?? [];
      const aHasRBR = transactionHasRBR(a, aViolations, currentUserEmail, currentUserAccountID, iouReport, policy, reportActions);
      const bHasRBR = transactionHasRBR(b, bViolations, currentUserEmail, currentUserAccountID, iouReport, policy, reportActions);
      if (aHasRBR === bHasRBR) {
-         return 0;
+         // Fall back to creation order when both transactions have the same RBR status,
+         // so a transient RBR (e.g. mid-smartscan) doesn't permanently reorder the carousel.
+         return (a.created ?? '').localeCompare(b.created ?? '');
      }
      return aHasRBR ? -1 : 1;
  }

After the change, step 4 of the repro re-sorts to [manual, scan] because manual's created precedes scan's — the smartscan completion correctly restores the original carousel position.

The created field is the source of truth for transaction creation time and isn't mutated by smartscan completion (smartscan updates modifiedCreated if it parses a different date from the receipt, but created remains the original transaction creation timestamp). Using localeCompare on the ISO string avoids the Date.parse allocation per comparison and gives stable lexicographic order on date strings.

What alternative solutions did you explore?

N/A

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.