[Due for payment 2026-06-23] Stabilize report subscriptions in the ReportActionItem tree

@mallenexpensify

Problem

ReportActionItem re-render stability regressed again on main. report-shaped useOnyx subscriptions in the ReportActionItem tree hand back new references with deep-equal content on nearly every render, causing wasted re-renders on the report screen (visible during message send).

Root causes:

A shared module-level getStableReportSelector makes every consumer on the same report key share one Onyx cache slot, churning references.
iouReport / chatReport subscribe to the full report, so they re-render on every last* heartbeat field (which change on every message send).
originalReport is subscribed in ReportActionItem rather than in its only consumer.

Fix

PR: #93421

Follow-up

Add a render-count / reference-stability test so CI catches the next regression instead of relying on manual profiling.
Monitor for a while to confirm stability holds.

Parent issue

$ #77176

Issue Owner

Current Issue Owner: @mallenexpensify

@cristipaval

@cristipaval
I worked today on performance tests to guard for this situation in the future.

I noticed that currently (locally and on CI) reassure performance tests always shows 0 for renders:

I managed to fix it with this small config change:
Config PR: #93573

I applied it only to perf files because it breaks standard unit tests that use jest.advanceTimersByTime().

After that, I prepared some improvements to the ReportActionsList performance tests:

Tests PR: [NoQA] Add ReportActionsList perf test case #93590
Made them more realistic by using data based on useOnyx + small clean up
Added another test that mocks 10 ADD_COMMENT actions with changes to the report's last* fields.

I checked the results, and without the fix from this merged PR, the render times are about 50% worse

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

Already confirmed it's not related to this PR: #93641 (comment)

@QichenZhu

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.4.8-3 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

[NoQA] stabilize stableReportSelector and more reports in the ReportActionItem tree #93421

If no regressions arise, payment will be issued on 2026-06-23. 🎊

For reference, here are some details about the assignees on this issue:

@QichenZhu requires payment through NewDot Manual Requests
@LukasMod does not require payment (Contractor)

@LukasMod

@cristipaval I worked today on performance tests to guard for this situation in the future.

I noticed that currently (locally and on CI) reassure performance tests always shows 0 for renders:
I managed to fix it with this small config change: Config PR: [#93573](https://github.com//pull/93573)
I applied it only to perf files because it breaks standard unit tests that use jest.advanceTimersByTime().

After that, I prepared some improvements to the ReportActionsList performance tests:

Tests PR: [NoQA] Add ReportActionsList perf test case #93590

Made them more realistic by using data based on useOnyx + small clean up

Added another test that mocks 10 ADD_COMMENT actions with changes to the report's last* fields.

I checked the results, and without the fix from this merged PR, the render times are about 50% worse

@LukasMod thanks for digging into this. Yes, this is the right direction.

Good catch on the render times showing 0. I checked the history and this is not an intentional change. It comes from the Jest 29 upgrade back in 2023, where we enabled modern fake timers globally. The modern fake timers also fake performance, and React's Scheduler reads performance once at load, so every render duration became 0. So the perf tests were silently not measuring renders for a long time. Fixing the measurement first makes sense. Otherwise any new regression test we add would not catch anything.

@QichenZhu

@QichenZhu Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

@mallenexpensify

Triggered auto assignment to @mallenexpensify (Awaiting Payment)

@QichenZhu

Payment Summary

Upwork Job

Reviewer: @QichenZhu owed $250 via NewDot
Contributor: @LukasMod does not require payment (Contractor)

BugZero Checklist (@mallenexpensify)

I have verified the correct assignees and roles are listed above and updated the necessary manual offers
I have verified that there are no duplicate or incorrect contracts on Upwork for this job (https://www.upwork.com/ab/applicants//hired)
I have verified the PR was not reverted
I have applied any discounts due to bugs/regressions introduced by this PR
I have paid out the Upwork contracts or cancelled the ones that are incorrect
I have verified the payment summary above is correct

BugZero Checklist:

[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.

Link to the comment on the PR: N/A. Not a bug.
Link to the comment on the Issue: N/A.
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.

Link to discussion: N/A.
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.

Not needed since this is a performance optimisation task and no UI changes.

@QichenZhu

Payment Summary

Contributor+: @QichenZhu due $250 via NewDot

@QichenZhu

approved $250 for @QichenZhu

Navigation Menu

Repository navigation

[Due for payment 2026-06-23] Stabilize report subscriptions in the ReportActionItem tree #93434

Problem

Fix

Follow-up

Parent issue

1 remaining item

Payment Summary

BugZero Checklist (@mallenexpensify)

BugZero Checklist:

Payment Summary

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Due for payment 2026-06-23] Stabilize report subscriptions in the ReportActionItem tree #93434

Description

Problem

Fix

Follow-up

Parent issue

Activity

LukasMod commented on Jun 15, 2026

melvin-bot commented on Jun 15, 2026

LukasMod commented on Jun 16, 2026

1 remaining item

melvin-bot commented on Jun 16, 2026

cristipaval commented on Jun 17, 2026

melvin-bot commented on Jun 19, 2026

melvin-bot commented on Jun 22, 2026

melvin-bot commented on Jun 22, 2026

Payment Summary

BugZero Checklist (@mallenexpensify)

QichenZhu commented on Jun 22, 2026

BugZero Checklist:

mallenexpensify commented on Jun 25, 2026

Payment Summary

trjExpensify commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions