fix: prevent empty expense report when category is disabled from another tab#92276
fix: prevent empty expense report when category is disabled from another tab#92276nabi-ebrahimi wants to merge 24 commits into
Conversation
|
@Krishna2323 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] |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 18c279a4d9
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| const reportTransactionsAndViolations = currentValue ? {...currentValue} : {}; | ||
| if (!transactions) { | ||
| return {}; | ||
| return reportTransactionsAndViolations; |
There was a problem hiding this comment.
When the transaction collection becomes undefined (for example during Onyx.clear() on logout/account reset, or any full collection reset), this now returns the previous derived value instead of {}. Because the derived-value manager passes currentValue from its in-memory cache and then writes the compute result back to Onyx, stale report transactions can be re-persisted after the source collection has been cleared, leaving old expenses visible or even leaking data into the next session. Violation-only updates are already handled later by falling back to previousTransaction, so the no-transactions case should still clear the derived value.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@Krishna2323 I fixed this by returning {} only when there is no violation update. For violation-only updates, we preserve the current derived value so the report transaction is not dropped. Could you please check it ?
|
@Krishna2323 The PR is ready for review. could you please a take a look when you get a chance ? thanks |
OnyxDerived keeps the last computed value in a module-local closure so future source updates can be merged against the previous derived state. When another tab updates the same derived key, the local closure can stay stale even though Onyx has the newer value. Subscribe to the derived key itself so external updates refresh the local snapshot. This prevents later partial source updates from recomputing from stale derived data and accidentally dropping existing report transaction state.
|
@Krishna2323 I also tested tags and taxes. The empty report bug reproduces for categories, tags, and taxes, and this fix resolves it for all three. |
@nabi-ebrahimi could you please share a recording of this bug? |
| sourceValues: undefined, | ||
| }; | ||
|
|
||
| Onyx.connectWithoutView({ |
There was a problem hiding this comment.
Why do we need this? I don't see it being mentioned in the selected proposal.
There was a problem hiding this comment.
Why do we need this?
derivedValue is tab-local memory used as context.currentValue. When another tab updates the derived Onyx key, this local value can stay stale. Then a violation-only update can recompute from an incomplete currentValue and write that incomplete result back to Onyx, causing the empty report.
This subscription keeps derivedValue synced with the persisted derived key across tabs.
I don't see it being mentioned in the selected proposal.
I found it while testing the selected fix against a wider cross-tab flow. Without this, the reducer fix still works only when the current tab already has the latest derived value, but it can still fail when context.currentValue is stale.
There was a problem hiding this comment.
The fix without the self-subscription doesn't work for me. Could you investigate an alternative to the self-subscription in index.ts?
On violation-only updates, instead of syncing the whole derived key closure, we could rebuild only missing transactions for the affected report(s) from the live COLLECTION.TRANSACTION dependency (violation keys + any txn in transactions but not in currentValue). That should fix Tab B writing an incomplete derived value without changing derived-engine behavior for all keys.
Self-subscription downsides: applies to every derived key, adds a race where an older callback can overwrite derivedValue, and can pull a bad cross-tab derived value into currentValue — not just good ones.
There was a problem hiding this comment.
@Krishna2323
I removed the self-subscription and investigated this path with logs. In the failing case, the violation-only update includes the new violation key, but that tab does not have the matching transaction in live COLLECTION.TRANSACTION or currentValue, so there is not enough data to rebuild the affected report.
Instead of publishing that incomplete recompute, I now skip the derived update when a violation-only update references an unresolved transaction. This keeps the fix scoped and avoids changing derived-engine behavior for all keys.
There was a problem hiding this comment.
@nabi-ebrahimi The transaction no longer disappears, but it brings back a deleted report:
https://github.com/user-attachments/assets/0166c13c-f90b-88f-95fc-d9e7fc98acb6
Could you investigate a proper solution and perform thorough testing?
Suggestion: Look into the ramOnlyKeys approach for this derived key — evaluate tradeoffs vs. the current fix.
There was a problem hiding this comment.
@Krishna2323 Thanks for catching this.
The deleted report was coming back because our previous fix preserved currentValue, but when a real transaction delete happened we only removed the transaction from the report bucket and left the empty bucket behind:
reportID: {
transactions: {},
violations: {},
}That empty derived bucket kept getting carried into later recomputes, so the deleted report could appear again even though it no longer had any transactions.
I investigated this more deeply with runtime logs across the full flow: create report → disable category → delete report → create another report → disable category again. The logs showed the violation-only guard was working correctly. The regression was specifically caused by stale empty report buckets surviving after a real TRANSACTION delete update.
I also tested the ramOnlyKeys approach for REPORT_TRANSACTIONS_AND_VIOLATIONS. It avoids syncing bad derived values across tabs, but it caused a worse regression: when creating an expense in Tab A, Tab B could render the expense/report empty because this derived value was no longer persisted/shared and Tab B had not recomputed it locally yet. So the tradeoff is not good here: it can hurt cross-tab rendering and startup/perf, which matches the concern already raised in the issue.
The updated fix keeps the current derived-key behavior and makes the reducer cleanup stricter:
- violation-only updates still cannot remove valid transaction membership
- real transaction delete/move updates still remove/move transactions
- after removing a transaction/violation, we now delete the report bucket if it becomes empty
- I added a regression test for deleting the last transaction from a report
I retested the original issue and the deleted-report regression, and both are working correctly now.
Could you please re-review again when you get a chance ? thanks
There was a problem hiding this comment.
@nabi-ebrahimi the bug is still there 🥲:
Monosnap.screencast.2026-06-23.19-32-06.mp4
There was a problem hiding this comment.
@nabi-ebrahimi have you found any better solutions or should we open the issue for new proposals? Do you have ETA?
There was a problem hiding this comment.
@Krishna2323 Yes, I’ve fixed the deleted-report regression and I’m now testing the full flow to make sure no other unexpected regressions were introduced. I’ll have the final solution ready by tomorrow. Thanks for your patience.
@Krishna2323 Sure. Screen.Recording.2026-06-03.at.5.31.43.PM.mov |
This comment was marked as outdated.
This comment was marked as outdated.
|
All contributors have signed the CLA ✍️ ✅ |
| @@ -8,29 +8,35 @@ const transactionReportIDMapping: Record<string, string> = {}; | |||
|
|
|||
| const transactionToReportIDMap: Record<string, string> = {}; | |||
There was a problem hiding this comment.
transactionToReportIDMap is never read — only deleted at line 110. We should remove it.
| sourceValues: undefined, | ||
| }; | ||
|
|
||
| Onyx.connectWithoutView({ |
There was a problem hiding this comment.
@nabi-ebrahimi the bug is still there 🥲:
Monosnap.screencast.2026-06-23.19-32-06.mp4
…ckets and deleted transactions during recompute
|
@Krishna2323 I fixed the reported regressions and tested the main flows again. Everything is working correctly on my side now. Tested flows:
REC-20260629121510.mp4
REC-20260629121615.mp4
REC-20260629122025.mp4Could you please re review again when you get a chance ? thanks |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a334fa102b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
|
This PR adds a new |
|
@Krishna2323 I have resolved the codex latest comment, could you please take another look when you get a chance ? thanks |
@nabi-ebrahimi, could you please start a Slack discussion about using I don’t expect pushback here since |
|
@Krishna2323, I’ve started the Slack discussion here. Thank you! |
|
@nabi-ebrahimi I think from looking at that thread, that the root problem with the tabs should be fixed now. Is that indeed the case and this PR can be closed out without merging? |
|
bump @nabi-ebrahimi |
|
@tgolen I checked again, and the issue is not fixed yet on my side. The related Onyx PR that should address the root cross-tab collection sync issue is still open/draft: Expensify/react-native-onyx#803 I can still reproduce the issue, so I don’t think this PR should be closed yet. |
|
OK, thank you. Have you tried to reproduce it with the Onyx fix in that PR? |
|
No yet, but I'll test it. thanks |
|
@tgolen I tested by temporarily pinning So it looks like the root issue will be fixed by the Onyx PR. cc @Krishna2323 |
|
@nabi-ebrahimi lets close this then. |
|
@Krishna2323 |
4 participants
Explanation of Change
This change prevents an expense report from appearing empty when only the transaction’s violations are refreshed, such as when a category is disabled from another tab. In that case, the transaction data may not be present in the update payload, but the existing expense should still remain visible in the report while its violation state is updated. The fix preserves the last known transaction for violation-only updates, while still allowing real transaction deletes or moves to remove the expense from its previous report as expected.
Fixed Issues
$ #91016
PROPOSAL: #91016 (comment)
Tests
Offline tests
Same as Tests.
QA Steps
Same as Tests.
// TODO: These must be filled out, or the issue title must include "[No QA]."
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, 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.ScrollViewcomponent to make it scrollable when more elements are added to the page.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
Screen.Recording.2026-06-02.at.6.16.08.AM.mov
Android: mWeb Chrome
Recording_20260602_061902.mp4
iOS: Native
Screen.Recording.2026-06-02.at.6.42.11.AM.mov
iOS: mWeb Safari
Screen.Recording.2026-06-02.at.7.23.06.AM.mov
MacOS: Chrome / Safari
Screen.Recording.2026-06-02.at.12.35.12.AM.mov