[$250] Spend - Default sort is descending

[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: 9.3.84-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91710
Email or phone of affected tester (no customers): applausetester+05272026_1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome
App Component: Other

Action Performed:

1. Open the staging.new.expensify.com website.
2. Create new report
3. Add two expenses to the report and force the second one of them to have a violation
4. Go to Spend -> Reports
5. Open the created report
6. Change sort to Total

Expected Result:

Verify you have the default sort (Date/ASC) set. RBR pre-sort is gone.

Actual Result:

Default sort for Date is set to DESC. RBR pre-sort is still at the top

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bandicam.2026-05-28.09-08-42-638.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7164951

[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/297f145c1eeb20e9d3e55802cae6333624c7b62935f10115ecdb0c62624c9de0

[MelvinBot]

Proposal

What is the root cause of that problem?

The sort toggle logic in SortableHeaderText.tsx:60 always defaults to DESC when clicking a column that isn't currently active:

const nextSortOrder = isActive && sortOrder === DESC ? ASC : DESC;

When isActive is false (i.e., switching to a different column), the ternary short-circuits to DESC regardless. So the flow is:

1. Report opens with Date/ASC (correct initial state at MoneyRequestReportTransactionList.tsx:285-288)
2. User clicks Total → isActive=false → sort becomes Total/DESC
3. User clicks Date again → isActive=false → sort becomes Date/DESC (bug: should be ASC)

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

Modify the nextSortOrder logic in SortableHeaderText.tsx:60 so that when switching to a non-active column, the default sort order is ASC instead of DESC. The toggle behavior (clicking an already-active column flips the order) should remain unchanged.

What alternative solutions did you explore? (Optional)

An alternative would be to handle this in the onSortPress callback of MoneyRequestReportTransactionList.tsx:741 by overriding the sort order when the column changes. However, fixing it in SortableHeaderText is cleaner since it's the shared component responsible for computing the next sort order and the same issue would affect any consumer. Note that this change would also affect the Search table headers that use the same component — this is likely the correct behavior there too (defaulting to ASC when first clicking a column), but should be verified during QA.

---

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.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-28 08:53:31 UTC.

Proposal

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

In a money request report's transaction table (Spend → Reports → open a report), after sorting by another column (e.g. Total) and then clicking the Date column header again, the Date column sorts descending instead of returning to the view's default Date/ASC. Because the RBR pre-sort only runs in Date/ASC, the violation transaction also no longer floats to the top.

What is the root cause of that problem?

The money request report table sets its default sort to Date/ASC (MoneyRequestReportTransactionList.tsx#L285-L291), and isDefaultSort (which gates the RBR-on-top pre-sort) is true only when sortBy === DATE && sortOrder === ASC.

But the sort direction for a freshly-clicked column is decided by the shared SortableHeaderText, which hardcodes DESC as the first direction for any column that isn't currently active (SortableHeaderText.tsx#L56-L60):

const nextSortOrder = isActive && sortOrder === CONST.SEARCH.SORT_ORDER.DESC ? CONST.SEARCH.SORT_ORDER.ASC : CONST.SEARCH.SORT_ORDER.DESC;

• For an inactive column the expression always evaluates to DESC.
• This is the correct first direction for Search, whose default order is genuinely DESC (SearchUIUtils.ts#L646).
• It is wrong for the money request report table, whose default order is ASC. So once you leave the Date column and click back on it, you land on Date/DESC — there is no way back to the Date/ASC default through the UI, which is exactly what QA hit on PR perf: precompute RBR transaction set in MoneyRequestReportTransactionList #91710's test step "Switch back to Date/ASC and verify the RBR-flagged item is back on top."

The component hardcodes a single DESC anchor for the "first click" of every column, ignoring that the host table's default order can be ASC. (Not in production because this table-based report view is staging-only.)

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

Make the "first direction for an inactive column" configurable in SortableHeaderText, defaulting to DESC so Search is unchanged, and have the money request report header pass ASC.

 type SearchTableHeaderColumnProps = WithSentryLabel & {
     text: string;
     icon?: IconAsset;
     isActive: boolean;
     sortOrder: SortOrder;
+    defaultSortOrder?: SortOrder;
     isSortable?: boolean;
     ...
 };

-export default function SortableHeaderText({text, icon, sortOrder, isActive, textStyle, containerStyle, isSortable = true, onPress, sentryLabel}: SearchTableHeaderColumnProps) {
+export default function SortableHeaderText({text, icon, sortOrder, isActive, defaultSortOrder = CONST.SEARCH.SORT_ORDER.DESC, textStyle, containerStyle, isSortable = true, onPress, sentryLabel}: SearchTableHeaderColumnProps) {

-    const nextSortOrder = isActive && sortOrder === CONST.SEARCH.SORT_ORDER.DESC ? CONST.SEARCH.SORT_ORDER.ASC : CONST.SEARCH.SORT_ORDER.DESC;
+    const nextSortOrder = isActive ? (sortOrder === CONST.SEARCH.SORT_ORDER.DESC ? CONST.SEARCH.SORT_ORDER.ASC : CONST.SEARCH.SORT_ORDER.DESC) : defaultSortOrder;

Supporting (text, no behavior change): thread the optional defaultSortOrder prop through SortableTableHeader and have MoneyRequestReportTableHeader pass defaultSortOrder={CONST.SEARCH.SORT_ORDER.ASC} to it. With this, clicking back onto Date returns to Date/ASC, isDefaultSort becomes true again, and the RBR-flagged transaction is re-floated to the top.

• Files: SortableHeaderText.tsx, SortableTableHeader.tsx, MoneyRequestReportTableHeader.tsx.
• Not touched: SearchTableHeader.tsx / Search behavior — the prop defaults to DESC, so Search keeps sorting new columns descending.
• Platforms: all (shared component).
• Verify: open a report with a violation; default = Date/ASC with RBR item on top; sort by Total; click Date → returns to Date/ASC and the RBR item is back on top.

What alternative solutions did you explore? (Optional)

• Consumer-only fix in MoneyRequestReportTransactionList's onSortPress: override the order when switching columns — const nextSortOrder = selectedSortBy === sortBy ? selectedSortOrder : CONST.SEARCH.SORT_ORDER.ASC; before setSortConfig. One-file and equally correct, but it leaves the shared component's DESC-only assumption in place for any future ASC-default table.
• Flip the shared anchor to ASC unconditionally: rejected — it would regress Search, whose default order is intentionally DESC.
• Make the Date header non-toggling / always reset to the default on click: rejected — it breaks the standard ascending⇄descending toggle users expect from a column header.

[MobileMage]

Proposal

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

In the money request report view (Spend → Reports → open a report), the initial default sort is Date/ASC so that RBR-flagged transactions are surfaced at the top. After clicking the Total column header to change sort, then clicking the Date column header again, Date sorts in DESC order instead of returning to the expected Date/ASC default. This contradicts step 8 of the test plan from the linked PR #91710 ("Switch back to Date/ASC and verify RBR-flagged item is back on the top") because clicking Date no longer restores the table's documented default ordering.

What is the root cause of that problem?

The READ side — MoneyRequestReportTransactionList — initialises sortConfig with {sortBy: DATE, sortOrder: ASC} and treats that combination as the "default sort" guard that triggers the RBR pre-sort path. The WRITE side — clicks coming up from SortableHeaderText — computes the next order with logic that does not know about this table's ASC default:

App/src/components/Search/SortableHeaderText.tsx

Lines 60 to 65 in 139b2c8

	const nextSortOrder = isActive && sortOrder === CONST.SEARCH.SORT_ORDER.DESC ? CONST.SEARCH.SORT_ORDER.ASC : CONST.SEARCH.SORT_ORDER.DESC;
	return (
	<View style={containerStyle}>
	<PressableWithFeedback
	onPress={() => onPress(nextSortOrder)}

Line 60 reads const nextSortOrder = isActive && sortOrder === DESC ? ASC : DESC. When the user clicks a column that is not currently active (isActive is false because sortBy === 'total' after step 6, and Date is being re-clicked in step 7), the expression short-circuits to the falsy branch and returns DESC. The press handler in MoneyRequestReportTransactionList then writes that order straight into state without translating it to the table's per-column default:

App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

Lines 741 to 746 in 139b2c8

	onSortPress={(selectedSortBy, selectedSortOrder) => {
	if (!isSortableColumnName(selectedSortBy)) {
	return;
	}
	setSortConfig((prevState) => ({...prevState, sortBy: selectedSortBy, sortOrder: selectedSortOrder}));
	}}

The full chain is therefore: user clicks Total → SortableHeaderText emits ('total', DESC) → state becomes {sortBy: 'total', sortOrder: 'DESC'} (correct behaviour for non-default columns) → user clicks Date → SortableHeaderText sees isActive=false for Date and emits ('date', DESC) → state becomes {sortBy: 'date', sortOrder: 'DESC'}. Because isDefaultSort on line 291 only fires when sortOrder === ASC, the RBR pre-sort path in rbrTransactionIDs (lines 297-311) is also bypassed, so the RBR-flagged transaction no longer floats to the top either. The behaviour in SortableHeaderText is the right global default for the main Search screen, which uses DESC as its defaultSortOrder in SearchUIUtils (line 646), but it is wrong for this specific table whose default is Date/ASC. The mismatch was latent before PR #91710 — the new test plan added the Total → Date round-trip step, which is why staging surfaces it but production (which still ran the old test plan) does not.

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

Fix it locally inside MoneyRequestReportTransactionList's onSortPress handler so the global SortableHeaderText keeps its existing behaviour for Search (which legitimately defaults to DESC). When the user clicks a column that is not the currently active sort column (i.e. selectedSortBy !== sortBy), use the table's per-column default: ASC when selectedSortBy === CONST.SEARCH.TABLE_COLUMNS.DATE, otherwise the incoming selectedSortOrder (DESC). When the user clicks the already-active column, honour selectedSortOrder so toggling Date between ASC and DESC still works.

App/src/components/MoneyRequestReportView/MoneyRequestReportTransactionList.tsx

Lines 741 to 746 in 139b2c8

	onSortPress={(selectedSortBy, selectedSortOrder) => {
	if (!isSortableColumnName(selectedSortBy)) {
	return;
	}
	setSortConfig((prevState) => ({...prevState, sortBy: selectedSortBy, sortOrder: selectedSortOrder}));
	}}

Concretely, inside the existing onSortPress callback after the isSortableColumnName guard, compute const nextOrder = selectedSortBy !== sortBy && selectedSortBy === CONST.SEARCH.TABLE_COLUMNS.DATE ? CONST.SEARCH.SORT_ORDER.ASC : selectedSortOrder and pass that as sortOrder into setSortConfig. This restores the original Date/ASC default on switch-back, which in turn re-arms isDefaultSort on line 291 and re-enables the RBR pre-sort that PR #91710 wanted to validate. The change is scoped to a single handler and a single column, does not modify any shared helper or other Search consumers, and preserves the column-toggle behaviour for repeated clicks on Date (DESC ↔ ASC) because the selectedSortBy !== sortBy check is false on a re-click of the active column.

What alternative solutions did you explore? (Optional)

Adding a per-column default-order map to SortableHeaderText (so the global component computes ASC for Date and DESC for everything else) was considered but rejected — it would change behaviour for the main Search screen and every other consumer of SortableTableHeader, where DESC is the intentional default (defaultSortOrder = DESC in SearchUIUtils.ts). Keeping the fix local to the one table that has an ASC default avoids any cross-screen regressions.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[github-actions]

⚠️ @MobileMage 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.