Filter DELETE-pending transactions out of LHN RBR aggregation - #97706
Filter DELETE-pending transactions out of LHN RBR aggregation#97706dilshodmackbook-sketch wants to merge 2 commits into
Conversation
Reverting a split leaves the split child transaction in Onyx marked pendingAction DELETE until the server confirms. getViolatingReportIDForRBRInLHN counted that lingering transaction's violation and kept the report's red-dot lit, while the opened report (which filters DELETE-pending transactions) looked clean. Filter DELETE-pending transactions from the RBR aggregation, mirroring the empty-report check in the same file. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@codex review |
|
Codex Review: Didn't find any major issues. Swish! Reviewed commit: ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
@marufsharifi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
| const transactions = getReportTransactions(potentialReport.reportID); | ||
| // Ignore transactions that are already pending deletion (e.g. a reverted split child) so the LHN RBR stays | ||
| // consistent with what the opened report renders, which also filters out DELETE-pending transactions. | ||
| const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE); |
There was a problem hiding this comment.
Reuse the existing isTransactionPendingDelete predicate instead of the raw comparison.
TransactionUtils already exports a named predicate for exactly this check:
https://github.com/Expensify/App/blob/main/src/libs/TransactionUtils/index.ts#L3001-L3003
For a transaction with a set pendingAction it's behaviorally identical to this line (the pendingFields branch in getTransactionPendingAction only ever yields UPDATE, never DELETE), so this is a safe swap:
const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => !isTransactionPendingDelete(transaction));isTransactionPendingDelete isn't imported into ReportUtils.ts yet, but this file already imports heavily from TransactionUtils, so just add it to that import. This keeps the intent ("skip transactions pending deletion") readable rather than hardcoding the CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE comparison.
| const transactions = getReportTransactions(potentialReport.reportID); | ||
| // Ignore transactions that are already pending deletion (e.g. a reverted split child) so the LHN RBR stays | ||
| // consistent with what the opened report renders, which also filters out DELETE-pending transactions. | ||
| const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE); |
There was a problem hiding this comment.
This "drop DELETE-pending transactions" filter is now the third copy of the same inline pattern in this file.
The same raw pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE filter over a transaction list already lives at:
- https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L9300 (treat report as empty once removal is queued)
- https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L13040-L13042 (
doesReportContainRequestsFromMultipleUsers, gated byshouldExcludeDeletedTransactions)
The comment on this new line even notes the opened-report path does the same filtering — that's the smell. Switching all three to !isTransactionPendingDelete(...) (see the other comment) collapses them onto one shared predicate.
Extracting a small getActiveReportTransactions / filterOutDeletedTransactions helper in TransactionUtils would make the reuse fully explicit, but that's a larger refactor and out of scope here — the predicate swap is the minimal DRY fix for this PR.
| const transactions = getReportTransactions(potentialReport.reportID); | ||
| // Ignore transactions that are already pending deletion (e.g. a reverted split child) so the LHN RBR stays | ||
| // consistent with what the opened report renders, which also filters out DELETE-pending transactions. | ||
| const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE); |
There was a problem hiding this comment.
Filter runs before the cheap isOpenOrProcessingReport early-return
getReportTransactions(...).filter(...) executes before the isOpenOrProcessingReport(potentialReport) guard just below (line 9459). For any report that isn't open/processing, both the transaction lookup and the new allocation-and-iterate are wasted. This is a pre-existing ordering issue — this PR only widens the wasted work by adding the .filter() to it. Per-report transaction lists are small and bounded, so the absolute cost is negligible even across many LHN rows; flagging only for a cheap cleanup.
Move the transactions computation below the early-return so it runs only for reports that survive the guard:
// Allow both open and processing reports to show RBR for violations
if (!isOpenOrProcessingReport(potentialReport)) {
return false;
}
const policy = allPolicies?.[`${ONYXKEYS.COLLECTION.POLICY}${potentialReport.policyID}`];
const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);| const transactions = getReportTransactions(potentialReport.reportID); | ||
| // Ignore transactions that are already pending deletion (e.g. a reverted split child) so the LHN RBR stays | ||
| // consistent with what the opened report renders, which also filters out DELETE-pending transactions. | ||
| const transactions = getReportTransactions(potentialReport.reportID).filter((transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE); |
There was a problem hiding this comment.
NAB: This line chains getReportTransactions(...).filter(...) with a long inline predicate, pushing it well past the width of the surrounding lines. The meaningful pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE check ends up buried at the tail of the line.
Consider extracting a named predicate so the intent reads at a glance:
const isNotPendingDeletion = (transaction: Transaction) => transaction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE;
const transactions = getReportTransactions(potentialReport.reportID).filter(isNotPendingDeletion);
| expect(result).toBeNull(); | ||
|
|
||
| await Onyx.clear(); | ||
| }); |
There was a problem hiding this comment.
Missing test: mixed DELETE-pending + live transaction on the same report.
Both this new test and the existing positive test use a single transaction, so nothing proves the filter is per-transaction (drops only the reverted child) rather than "if any transaction is DELETE-pending, drop the whole report's RBR." That's the exact split-report shape this fix targets.
Please add, right after this test:
it('should still surface RBR when a report has a live violating transaction alongside a DELETE-pending one', async () => {
// ...same policy / chatReport / expenseReport setup as the pending-delete test...
// Two violating transactions on the SAME expense report:
// one reverted split child (DELETE-pending) and one still live.
const deletedChild: Transaction = {
...createRandomTransaction(809),
transactionID: 'transaction-rbr-mixed-deleted',
reportID: expenseReportID,
amount: 5000,
currency: CONST.CURRENCY.USD,
status: CONST.TRANSACTION.STATUS.POSTED,
reimbursable: true,
pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE,
};
const liveChild: Transaction = {
...createRandomTransaction(810),
transactionID: 'transaction-rbr-mixed-live',
reportID: expenseReportID,
amount: 5000,
currency: CONST.CURRENCY.USD,
status: CONST.TRANSACTION.STATUS.POSTED,
reimbursable: true,
// no pendingAction
};
// Give BOTH transactions a MISSING_CATEGORY violation, then merge policy/reports/
// transactions/violations into Onyx as in the tests above.
const result = getViolatingReportIDForRBRInLHN(chatReport, transactionViolationsCollection);
expect(result).toBe(expenseReportID); // RBR still shown because the live child violates
await Onyx.clear();
});Verdict: Covered 2/3 changed behaviors — the mixed-transaction case is the one gap, and it's the realistic split-report scenario the fix is about.
| await waitForBatchedUpdates(); | ||
|
|
||
| const result = getViolatingReportIDForRBRInLHN(chatReport, transactionViolationsCollection); | ||
| expect(result).toBeNull(); |
There was a problem hiding this comment.
Add a positive control so this test can't pass vacuously.
Right now the test only asserts the DELETE-pending case returns null. That doesn't prove the filter is what produces the null — if any unrelated gate in getViolatingReportIDForRBRInLHN (isCurrentUserSubmitter, isOpenOrProcessingReport, or shouldShowViolation rejecting MISSING_CATEGORY) were the real reason, the test would still pass while testing nothing, and it would keep passing even if the fix were reverted in a way that broke a different gate.
Please assert that the same setup lights the RBR when the transaction is not pending deletion. Cheapest version — flip pendingAction and re-assert right after line 15471:
// Positive control: the same violating transaction lights the RBR when it isn't pending deletion.
await Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {pendingAction: null});
await waitForBatchedUpdates();
expect(getViolatingReportIDForRBRInLHN(chatReport, transactionViolationsCollection)).toBe(expenseReportID);This guarantees the test actually exercises the new filter (and would fail on main), instead of relying on QA step 6 to cover the positive case.
|
@MelvinBot Review |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeiOS: HybridAppiOS: mWeb SafariMacOS: Chrome / Safari |
Review — LGTM ✅The fix is correct, minimal, and well-placed. Filtering VerificationThe filter propagates to all four downstream checks. Each honors the passed array rather than re-fetching:
Pattern matches existing code. The test is meaningful. The new case is a byte-for-byte clone of the existing positive test (I couldn't execute Jest in this sandboxed run, so the test-behavior claim above is from code analysis, not a local run — CI's Non-blocking observationOther violation aggregators — This is an automated review from MelvinBot — not a substitute for the human reviewer checklist. Reply with |
|
@dilshodmackbook-sketch, could you please check the above comments. |
…, cover mixed case - Swap the raw pendingAction !== DELETE comparisons for the existing isTransactionPendingDelete predicate across all three call sites in ReportUtils. - Move the transaction filter below the isOpenOrProcessingReport early-return so it only runs for reports that survive the guard. - Add a positive control to the pending-delete RBR test and a mixed live + DELETE-pending test proving the filter is per-transaction. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
@marufsharifi Done. |
3 participants
Explanation of Change
Reverting a split on a report removes the split child transaction(s) optimistically — they are marked with
pendingAction: DELETEand stay in Onyx (with theirreportIDand theirtransactionViolationsentry) until the server confirms and nulls them.The LHN red-dot (RBR) is computed by
getViolatingReportIDForRBRInLHNinsrc/libs/ReportUtils.ts. It built the report's transaction set with a plaingetReportTransactions(...)and did not exclude transactions that are pending deletion. That set is passed down intohasVisibleViolationsForUser/hasViolations/hasWarningTypeViolations/hasNoticeTypeViolationsForRBRInLHN, each of which readstransactionViolations_<transactionID>for every transaction — so aDELETE-pending transaction whose violation entry still existed kept the red dot lit.Meanwhile the report contents (and the sibling "is this report empty" check a few lines above in the same file) already filter out
DELETE-pending transactions, which is why the opened report looked clean. The LHN aggregation and the report view disagreed about whether the reverted transaction still existed.This PR makes the RBR aggregation ignore transactions that are already pending deletion, mirroring the empty-report check in the same function:
Because this filtered array is the one handed to every downstream violation check, the single change fixes the whole RBR path in one place and keeps the LHN consistent with what the opened report actually renders — for reverted splits and any other flow that leaves a transaction queued for deletion.
A unit test was added to
tests/unit/ReportUtilsTest.tscovering the case where the only violating transaction isDELETE-pending, assertinggetViolatingReportIDForRBRInLHNreturnsnull.Fixed Issues
$ #96967
PROPOSAL: #96967 (comment)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectionAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
96967-android.mp4
Android: mWeb Chrome
video_2026-08-04_00-12-57.mp4
iOS: Native
96967-ios.mp4
iOS: mWeb Safari
video_2026-08-04_00-12-59.mp4
MacOS: Chrome / Safari
96967-macos-chrome.online-video-cutter.com.mp4