[Due for payment 2026-03-04] [$250] Eliminate redundant sorting in LHN renderItem

[mountiny]

Coming from proposal here

Background:

The LHN renders a scrollable list of all user-visible reports via a FlashList renderItem callback. For each report row, renderItem derives several values from that report's actions: the last visible action, the last displayable action, the one-transaction thread report ID, and the last IOU money request action. Report actions are stored as unsorted objects in Onyx. A collection-level Onyx callback on ONYXKEYS.COLLECTION.REPORT_ACTIONS already fires on every data change and iterates over all report-action collections to maintain pre-computed caches (allSortedReportActions, lastReportActions, lastVisibleReportActions). Additionally, the reportAttributes OnyxDerived config already computes per-report metadata reactively whenever its Onyx dependencies change.

Problem:

When the LHN re-renders on a heavy account, each renderItem call independently performs two sort operations, a filter pass, and a find scan over that report's actions, which slows down initial navigation to the inbox and degrades scroll frame rates as the number of reports grows

Solution:

1. Expose oneTransactionThreadReportID through the existing reportAttributes OnyxDerived config which already computes it but was discarding it so renderItem reads it reactively instead of calling getOneTransactionThreadReportID() per item.
2. Merge the .filter() and .find() passes in the REPORT_ACTIONS collection callback into a single for loop with early break, caching results in lastVisibleReportActions and lastVisibleIOUMoneyActions.
3. Replace the two per-item sort calls with a single-pass findLastReportActions() using an isNewerReportAction comparator, reducing per-item complexity

Draft PR
Performance gain:
ManualNavigateToInboxTab span reduced ~30ms

Issue Owner

Current Issue Owner: @bfitzexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024766686700575645
• Upwork Job ID: 2024766686700575645
• Last Price Increase: 2026-03-02

[melvin-bot]

Triggered auto assignment to @bfitzexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

When the LHN (Left Hand Navigation) re-renders on a heavy account, each renderItem call independently performs two O(n log n) sort operations, a filter pass, and a find scan over that report's actions. This slows initial navigation to the inbox and degrades scroll frame rates as the number of reports grows.

What is the root cause of that problem?

The root cause is redundant per-item computation in renderItem at src/components/LHNOptionsList/LHNOptionsList.tsx:210-258. For each visible report row, renderItem performs:

1. Operation 1 (line 210-211): Calls getSortedReportActionsForDisplay(itemReportActions, canUserPerformWrite) — which does O(n) filter + O(n) replaceBaseURLInPolicyChangeLogAction map + O(n) withDEWRoutedActionsArray flatMap + O(n log n) sort — then takes .at(0) for lastReportAction.

2. Operation 2 (lines 248-258): Calls getSortedReportActions(Object.values(itemReportActions)) — O(n log n) ascending sort — then filters with shouldReportActionBeVisibleAsLastAction + excludes CREATED, and takes .at(-1) for lastAction.

Both operations only need a single "maximum" element, yet they sort the entire array. Meanwhile:

• A collection-level Onyx callback in src/libs/OptionsListUtils/index.ts:240-297 already pre-computes lastVisibleReportActions and lastReportActions caches (used internally by getLastMessageTextForReport which renderItem already calls), but these caches are module-private and not consumed by renderItem directly.
• generateReportAttributes in src/libs/ReportUtils.ts:12489 already computes oneTransactionThreadReportID but the OnyxDerived config at src/libs/actions/OnyxDerived/configs/reportAttributes.ts:204 discards it by only destructuring {hasAnyViolations, requiresAttention, reportErrors}.

The net result for N visible rows is 2*N sorts + 2*N filters running synchronously during render, when simpler approaches (single-pass max-finding, reusing already-computed derived values) would suffice.

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

Draft PR #82648 implements two main changes:

Change 1 — Expose oneTransactionThreadReportID from reportAttributes OnyxDerived config.

• Add oneTransactionThreadReportID to the destructuring at reportAttributes.ts:204, include it in the stored acc[report.reportID] object at line 222, and extend the ReportAttributes type in DerivedValues.ts.
• This lets renderItem read the already-computed value reactively (itemReportAttributes?.oneTransactionThreadReportID) instead of calling getOneTransactionThreadReportID() per row.
• Assessment: This change is sound and safe. The value is already computed; it was simply discarded. The parameters used in generateReportAttributes are semantically equivalent to those used in the LHN call.

Change 2 — Replace two per-item sorts with single-pass findLastReportActions().

• A new findLastReportActions() function in ReportActionsUtils.ts iterates through report actions once, tracking two separate "winners" (lastVisibleAction and lastActionForDisplay) using an isNewerReportAction comparator.
• The isNewerReportAction comparator correctly replicates all 4 tiebreaking levels of the existing getSortedReportActions sort (CREATED pinning, timestamp, REPORT_PREVIEW priority, reportActionID fallback).
• Assessment: This change has correctness concerns that should be reviewed. Specifically:
  1. Missing withDEWRoutedActionsArray: The old Pass 1 (getSortedReportActionsForDisplay) calls withDEWRoutedActionsArray, which injects synthetic DYNAMIC_EXTERNAL_WORKFLOW_ROUTED actions timestamped 1ms after their parent (ReportActionsUtils.ts:1325-1338). These synthetic actions can become the lastReportAction. The new findLastReportActions() iterates only raw Onyx data, so it will never find a synthetic DEW action. For reports with workflow submit/forward as their newest action, lastVisibleAction may differ from the old lastReportAction.
  2. Missing replaceBaseURLInPolicyChangeLogAction: The old code transforms policy changelog action HTML by replacing %baseURL. The new code skips this, so any lastVisibleAction that is a policy changelog action will have un-transformed message HTML.
  3. Filter alignment: The new code uses shouldReportActionBeVisible for lastVisibleAction (matching old Pass 1) and shouldReportActionBeVisibleAsLastAction for lastActionForDisplay (matching old Pass 2). This part is correctly implemented.

What alternative solutions did you explore? (Optional)

An alternative approach would be to lift the existing module-private caches (lastVisibleReportActions, lastReportActions) from OptionsListUtils/index.ts into exported functions or into the OnyxDerived config, so renderItem could read pre-computed values instead of recomputing them. This would avoid any risk of semantic divergence from the single-pass approach, though it would require the caches to apply the exact filter predicates needed by renderItem (currently there are subtle differences between the cache filter and renderItem's filters).

---

Next Steps for Contributor+ team: The oneTransactionThreadReportID exposure (Change 1) is clean and ready. The findLastReportActions() single-pass approach (Change 2) should be verified against reports with Dynamic External Workflow (DEW) routed actions and policy changelog actions to ensure the missing withDEWRoutedActionsArray and replaceBaseURLInPolicyChangeLogAction transforms don't cause regressions. Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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