[Due for payment 2026-04-28] [$250] Performance: reportAttributes recomputed all reports on transaction-only Onyx updates

[mountiny]

Problem

When editing an expense (merchant, amount, description, etc.), the reportAttributes Onyx-derived value could recompute all reports in the collection (e.g. ~15k) instead of only the affected report(s).

dataToIterate starts as Object.keys(reports) (full set). On the incremental path it was only narrowed when updates.length > 0 (report / metadata / actions / nameValuePairs changes). When only a transaction update fired, updates stayed empty while transactionsUpdates was set — the incremental branch ran but dataToIterate was never scoped down, so transaction report IDs were merged into the full list and every report was recomputed.

Expected outcome

In the incremental update path, only reports that actually need recomputation should be processed (e.g. reset dataToIterate when entering that branch so transaction-driven updates do not retain the full key set).

Impact

On a high–report-count account, fixing this avoided unnecessary work; author measured ~800ms improvement when updating an expense on iOS (~15k reports).

Implementation

Merged in: #87747

Related

• PR: #87747 — Fix reportAttributes recomputing all reports on transaction updates
• Linked from PR: #80560

QA / verification

• Edit an expense (e.g. amount); confirm values and UI stay correct.
• No new JS console errors on that flow.
• Spot-check high–traffic / many-reports account if possible.

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044206573804629774
• Upwork Job ID: 2044206573804629774
• Last Price Increase: 2026-04-15

[mountiny]

PR merged

[MelvinBot]

Issue Analysis

Root Cause: In reportAttributes.ts:185-188, the incremental update branch entered when any update type was present (transactions, violations, or policy tags), but dataToIterate was only narrowed from the full Object.keys(reports) set when updates.length > 0. When only a transaction update fired (e.g., editing an expense), updates was empty, so dataToIterate retained all ~15k report keys — every report was recomputed unnecessarily.

Fix (merged in #87747): A single line — dataToIterate = []; — resets the iteration set at the top of the incremental branch before conditionally appending only the affected report keys. This ensures transaction-only, violation-only, or policyTag-only updates only recompute the reports they actually touch.

Evidence

The diff adds one line at L188:

 if (useIncrementalUpdates) {
     if (updates.length > 0 || !!transactionsUpdates || !!transactionViolationsUpdates || !!policyTagsUpdates) {
+        dataToIterate = [];
         if (updates.length > 0) {
             dataToIterate = prepareReportKeys(updates);

Before this fix, dataToIterate was initialized to Object.keys(reports) at L159 and only replaced inside the if (updates.length > 0) block. The outer condition could be true from transactionsUpdates alone, but without entering the inner block, dataToIterate stayed as the full report set. The transaction report IDs were then appended to that full set, making the dedup at L225 ineffective.

Confidence: High — the one-line fix directly addresses the described symptom, the author measured ~800ms improvement on iOS with ~15k reports, and no alternative explanations remain.

Verification: Edit an expense (amount, merchant, description) and confirm the UI updates correctly. No new JS console errors should appear. The fix is already merged.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Current assignee @abzokhattab is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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