Clear iouReportID on parent chat when unapproving cancelled expense report#91563
Clear iouReportID on parent chat when unapproving cancelled expense report#91563MelvinBot wants to merge 6 commits into
Conversation
… report After Pay → Cancel payment → Unapprove, the parent chat's iouReportID still points to the old expense report. When the admin then creates a new expense from the FAB, it gets appended to the cancelled-and-unapproved report instead of creating a fresh one. unapproveExpenseReport now clears iouReportID on the parent chat report (with a matching failureData entry to restore it on rollback), mirroring the cleanup that submitReport already performs. Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
|
@MelvinBot Please add a simple test case for this change |
Verify that unapproveExpenseReport optimistically clears iouReportID on the parent chat report when chatReportID is present, and restores it in failureData for rollback. Also verify no parent chat update is added when chatReportID is absent. Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
|
Added two test cases in a new
Both tests pass locally ✅ |
…type Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
|
Fixed the failing |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1e7aab8c81
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| onyxMethod: Onyx.METHOD.MERGE, | ||
| key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`, | ||
| value: { | ||
| iouReportID: expenseReport.reportID, |
There was a problem hiding this comment.
Restore prior chat iouReportID on unapprove rollback
The failure rollback now hard-codes iouReportID: expenseReport.reportID, which can corrupt chat state when the API call fails and the chat’s prior pointer was null (or pointed to a different report). In that case, the rollback introduces a stale pointer to an approved/cancelled report, so later FAB expenses can be routed to the wrong report. The rollback should restore the previous chat iouReportID value (read before optimistic mutation) rather than always writing the current expense report ID.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed. The failure rollback now reads the chat report's actual iouReportID via getReportOrDraftReport before the optimistic mutation and restores that value instead of hard-coding expenseReport.reportID. Updated the test to verify this by seeding a chat report with a different iouReportID and asserting it's properly restored on failure.
Read the chat report's actual iouReportID via getReportOrDraftReport before the optimistic mutation and use that value in failureData, instead of hard-coding expenseReport.reportID. This prevents corrupting chat state when the prior pointer was null or pointed to a different report. Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
| // iouReportID so the next expense from the FAB creates a fresh report instead of | ||
| // appending to the cancelled-and-unapproved one. This mirrors submitReport's cleanup. | ||
| const chatReport = expenseReport.chatReportID ? getReportOrDraftReport(expenseReport.chatReportID) : undefined; | ||
| if (chatReport) { |
There was a problem hiding this comment.
@MelvinBot Please add expenseReport.isCancelledIOU check here to narrow the fix to the cancel-payment bug. Do the same for failureData
There was a problem hiding this comment.
Done. Added expenseReport.isCancelledIOU guard to both the optimistic and failure data blocks. Updated the test to set isCancelledIOU: true and renamed the negative test case to verify the guard (isCancelledIOU: false → no parent chat update).
Add expenseReport.isCancelledIOU guard to both the optimistic and failure data blocks that clear/restore iouReportID on the parent chat. This ensures the fix only applies to the cancel-payment → unapprove flow and does not affect normal unapprove operations. Update test to set isCancelledIOU: true and rename the negative test to verify the guard (isCancelledIOU: false skips the update). Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
|
MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR. Next steps: A human should review the recent commits and resolve the conflicting CI errors manually. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4100392910
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| onyxMethod: Onyx.METHOD.MERGE, | ||
| key: `${ONYXKEYS.COLLECTION.REPORT}${chatReport.reportID}`, | ||
| value: { | ||
| iouReportID: chatReport.iouReportID ?? null, |
There was a problem hiding this comment.
Avoid stale iouReportID rollback after concurrent updates
The rollback path restores chatReport.iouReportID unconditionally, which can overwrite newer optimistic state if the user creates another expense before UNAPPROVE_EXPENSE_REPORT fails. In that case, money-request creation updates the same chat report’s iouReportID to the new report, but this failure merge reverts it back to the old cancelled report ID, causing later FAB expenses to attach to the wrong report again. This should only restore when the pointer is still in the expected pre-unapprove state (or otherwise guard against clobbering newer writes).
Useful? React with 👍 / 👎.
|
@MelvinBot Please add tests in the PR description that verify the implemented fix and complete all checkboxes in the PR Author Checklist |
|
Updated the PR description:
|
|
@MelvinBot Update the test steps to this and set the QA steps and Offline tests to "Same as Tests" TestsPrecondition:
|
|
Updated the PR body:
|
|
@MelvinBot Please mark the PR as ready for review |
|
@nyomanjyotisa 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] |
|
Done — PR is now marked as ready for review ✅ |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4100392910
ℹ️ 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".
| if (chatReport && expenseReport.isCancelledIOU) { | ||
| optimisticData.push({ | ||
| onyxMethod: Onyx.METHOD.MERGE, | ||
| key: `${ONYXKEYS.COLLECTION.REPORT}${chatReport.reportID}`, | ||
| value: { | ||
| iouReportID: null, | ||
| }, |
There was a problem hiding this comment.
Clear chat pointer only when it matches this report
The new isCancelledIOU branch clears the parent chat’s iouReportID unconditionally whenever a chat report exists, but it does not verify that the pointer currently targets the report being unapproved. If another expense report has already become the active chat pointer (for example from another tab/device or a prior optimistic update), this code will wipe that newer pointer and cause subsequent FAB expenses to be routed to an unintended fresh report. Please gate this clear on chatReport.iouReportID === expenseReport.reportID (or equivalent) before nulling it.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
It's an edge case, but still worth handling. @MelvinBot Could you address this?
There was a problem hiding this comment.
Done. Both the optimistic and failure blocks now check chatReport.iouReportID === expenseReport.reportID before clearing. Added a test for the mismatch case (chat points to a different report → no clearing happens).
Only clear the parent chat's iouReportID when it currently points to the expense report being unapproved. This prevents wiping a newer pointer set by a concurrent expense or another tab/device. Co-authored-by: Nyoman Jyotisa <nyomanjyotisa@users.noreply.github.com>
|
@neil-marcellini 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] |
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid-Native.mp4Android: mWeb ChromeAndroid-mWeb.Chrome.mp4iOS: HybridAppiOS-Native.mp4iOS: mWeb SafariiOS-mWeb.Safari.mp4MacOS: Chrome / SafariMacOS-Chrome.mp4 |
|
Closing this since the issue is not reproducible. Lmk if you disagree for some reason. |
Explanation of Change
After the Pay → Cancel payment → Unapprove sequence on an expense report, the parent chat's
iouReportIDstill points to the old expense report. When the admin creates a new expense from the FAB, it gets appended to the cancelled-and-unapproved report instead of creating a fresh one.unapproveExpenseReportnow clearsiouReportIDon the parent chat report (with a matchingfailureDataentry to restore it on rollback), mirroring the cleanup thatsubmitReportalready performs.Fixed Issues
$ #89203
PROPOSAL: #89203 (comment)
Tests
Precondition:
Offline tests
Same as Tests
QA Steps
Same as Tests
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
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari