Fix stale members list when resolving mention whisper in transaction thread#89363
Fix stale members list when resolving mention whisper in transaction thread#89363
Conversation
… transaction thread When viewing a transaction thread directly, parentReport equals the current report, so the guard parentReport.reportID !== reportID skips the parent participant update. This leaves the IOU report members list stale until the server responds. Fall back to report.parentReportID to find the actual ancestor (IOU/expense/invoice report) and apply the optimistic participant update there. Co-authored-by: dukenv0307 <dukenv0307@users.noreply.github.com>
|
The Re-running the failed job now. |
…-ternary rule Co-authored-by: dukenv0307 <dukenv0307@users.noreply.github.com>
|
Fixed the ESLint The |
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
Reviewer Checklist
Screenshots/VideosAndroid: HybridAppAndroid: mWeb ChromeScreen.Recording.2026-05-02.at.10.03.56.moviOS: HybridAppScreen.Recording.2026-05-02.at.10.09.14.moviOS: mWeb SafariScreen.Recording.2026-05-02.at.10.05.34.movMacOS: Chrome / SafariScreen.Recording.2026-05-02.at.09.55.16.movScreen.Recording.2026-05-02.at.09.57.19.mov |
|
@MelvinBot I completed the checklist and added the videos for all platforms. Please add the following test steps and complete your checklist above
|
|
Done — added the test steps to the Tests, Offline tests, and QA Steps sections, and completed the author checklist. |
|
❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table. src/libs/actions/Report/index.ts 69.49% <66.66%> (-0.07%) ⬇️ @MelvinBot Please add the test case to avoid the issue above |
Covers the new code path where parentReport matches the current report and the function falls back to report.parentReportID to find the ancestor IOU/money-request report for optimistic participant updates. Co-authored-by: dukenv0307 <dukenv0307@users.noreply.github.com>
|
Added a test case covering the new ancestor report fallback path in |
|
@MelvinBot Open the PR |
|
PR is now marked as ready for review. |
melvin-bot
Bot
requested review from
dukenv0307 and
joekaufmanexpensify
and removed request for
a team and
dukenv0307
|
@dukenv0307 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: d17041bfbe
ℹ️ 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".
| } | ||
| let parentReportIDForUpdate: string | undefined; | ||
| if (parentInviteData) { | ||
| parentReportIDForUpdate = parentReport?.reportID !== reportID ? parentReport?.reportID : report?.parentReportID; |
There was a problem hiding this comment.
When the new fallback path sets parentInviteData from report.parentReportID (because parentReport is absent), this ternary still treats parentReport?.reportID !== reportID as true and assigns parentReportIDForUpdate to undefined. In that case both optimistic and failure merges for the ancestor are skipped, so the fallback silently does nothing even though ancestor invite data was built. This can happen when resolving an invite whisper from a child report before parentReport is available in props/state.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — this is a real bug. When parentReport is undefined (which happens when originalReport is falsy in the caller at MentionWhisperContent.tsx:54), the expression parentReport?.reportID !== reportID evaluates to undefined !== someID = true, so parentReportIDForUpdate gets assigned undefined instead of falling through to report?.parentReportID.
Fixed by adding a truthiness check: index.ts:5512 now uses parentReport?.reportID && parentReport.reportID !== reportID so the else branch correctly assigns report?.parentReportID.
|
All CI checks are passing — nothing to fix. |
|
Use ancestor ID when parentReport is undefined When the new fallback path sets parentInviteData from report.parentReportID (because parentReport is absent), this ternary still treats parentReport?.reportID !== reportID as true and assigns parentReportIDForUpdate to undefined. In that case both optimistic and failure merges for the ancestor are skipped, so the fallback silently does nothing even though ancestor invite data was built. This can happen when resolving an invite whisper from a child report before parentReport is available in props/state. @MelvinBot Please check it |
…ined parentReport When parentReport is undefined (originalReport is falsy in caller), parentReport?.reportID !== reportID evaluates to true (undefined !== string), causing parentReportIDForUpdate to be assigned undefined instead of falling through to report?.parentReportID. Co-authored-by: dukenv0307 <dukenv0307@users.noreply.github.com>
|
@dukenv0307 @Valforte One of you needs to 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] |
|
@codex review |
|
Codex Review: Didn't find any major issues. Hooray! ℹ️ 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". |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| } | ||
| let parentReportIDForUpdate: string | undefined; | ||
| if (parentInviteData) { | ||
| parentReportIDForUpdate = parentReport?.reportID && parentReport.reportID !== reportID ? parentReport.reportID : report?.parentReportID; |
There was a problem hiding this comment.
❌ CONSISTENCY-3 (docs)
The condition parentReport?.reportID && parentReport.reportID !== reportID is duplicated on lines 5503 and 5512. Both check the same thing: whether parentReport is a distinct report from the current one. This duplication increases the risk of the two checks diverging during future edits.
Extract the check into a boolean computed once, then reuse it:
const isParentReportDifferent = !!parentReport?.reportID && parentReport.reportID !== reportID;
let parentInviteData = isInviteResolution && isParentReportDifferent ? buildParticipantsInviteData(parentReport, inviteeAccountIDs) : undefined;
// ... fallback logic ...
let parentReportIDForUpdate: string | undefined;
if (parentInviteData) {
parentReportIDForUpdate = isParentReportDifferent ? parentReport.reportID : report?.parentReportID;
}Reviewed at: 95ba3a2 | Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
There was a problem hiding this comment.
Fixed — extracted the duplicated condition into isParentReportDifferent and reused it in both places.
|
CONSISTENCY-3 (docs) Extract the check into a boolean computed once, then reuse it: const isParentReportDifferent = !!parentReport?.reportID && parentReport.reportID !== reportID; let parentInviteData = isInviteResolution && isParentReportDifferent ? buildParticipantsInviteData(parentReport, inviteeAccountIDs) : undefined; @MelvinBot Pls fix |
…boolean Co-authored-by: dukenv0307 <dukenv0307@users.noreply.github.com>
2 participants
Explanation of Change
When a user views a transaction thread directly and clicks "Invite to chat" on a mention whisper, the
parentReportpassed toresolveActionableMentionWhisperis the same object asreport(the transaction thread itself). This means the guardparentReport.reportID !== reportIDevaluates tofalse, so the IOU/expense report never gets an optimistic participant update — its Members page stays stale until the server responds.This PR adds a fallback: when
parentInviteDatais undefined (becauseparentReportmatched the current report), we look up the actual ancestor report viareport.parentReportID. If that ancestor is a money-request or invoice report, we applybuildParticipantsInviteDatato it, so the Members list updates immediately.Fixed Issues
$ #88706
Tests
Offline tests
QA Steps
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