Narrow per-row report actions subscriptions in ReportActionItem

[sosek108]

Explanation of Change

This targets the Onyx store bump in Expensify#98956.

Every ReportActionItem row ran useOriginalReportID and useReportsParentHierarchy. The first rebuilt all of the report's actions into a fresh object in every row on every actions write and deep-compared it, read the full report without a selector, and read the account-wide transactions and violations context. The second subscribed every row to the whole report collection, only to pass the hierarchy to the dismiss-error handler. So editing one message, a write to a heartbeat field of the report, or a write to any report or transaction in the account re-rendered every row.

useOriginalReportID now checks whether the action belongs to the current report with a boolean selector, reads the three report fields it needs with primitive selectors, and subscribes to the full actions, chat report and transactions only for rows whose action comes from a merged transaction thread. Rows read only the viewed report's ancestor chain through a new useReportAncestorsHierarchy, which is all clearAllRelatedReportActionErrors walks.

A new reassure test with 500 actions and 10 writes per scenario runs unchanged on the base and on this branch. A write to an unrelated report goes from 364.3 ms to 113.5 ms, editing one visible action from 259.0 ms to 185.6 ms, a write to a heartbeat field of the report from 319.8 ms to 239.4 ms, and a write to an unrelated transaction from 299.1 ms to 225.8 ms. A report name change and mount are unchanged. With 46 rows mounted, editing one action re-renders 1 row instead of 46.

Fixed Issues

$ https://github.com/callstack-internal/expensify-issues/issues/3039
PROPOSAL:

Tests

1. Open a chat with many messages. Edit one message and verify only that message shows the edit.
2. Open an expense report with a single expense. Verify the actions from its transaction thread show, and their context menu actions (reply in thread, copy link) work.
3. Open a thread. Verify the parent action shows at the top.
4. Add a reaction to a message. Verify it appears on that message.
5. Trigger an error on a message (for example, an attachment upload that fails) and dismiss it. Verify the error clears on the message and on the thread's parent action.

• Verify that no errors appear in the JS console

Offline tests

1. Go offline.
2. Send and edit a message. Verify both show as pending.
3. Go back online. Verify the message is sent and the edit is kept.

QA Steps

Same as tests.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption.

_{Comment @coderabbitai help to get the list of available commands.}