Chat - Not all whispers from Concierge are deleted after deleting message containing mention

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.42-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #82720
Email or phone of affected tester (no customers): skdpmoskpskspskd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Mention User A and send the message.
4. Edit the message, mention User B and save it.
5. Delete the message.

Expected Result:

Both whispers from Concierge will be deleted.

Actual Result:

Only the first whisper from Concierge is deleted.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Krishna2323

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #82720

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #82720 - "Delete user MENTIONWHISPER when ADDCOMMENT is deleted" by @deetergp (High confidence)
Related Issues: #63874 (original issue that #82720 fixed)

Recommendation: ROLL FORWARD

The deletion logic in PR #82720 needs to be enhanced to handle whispers created during message edits. A simple revert would reintroduce the original bug (#63874). The fix should be straightforward: the deletion logic needs to find and delete ALL unresolved whispers associated with the parent comment, not just those at parentCommentID + 1 and parentCommentID + 2.

Labels: Keeping both DeployBlockerCash labels as this is a frontend bug that requires an App fix.

📋 Detailed Analysis

Evidence

PR #82720 was explicitly mentioned in the issue as the source: #82720. The PR was merged on 2026-03-20 and is included in the current staging deploy (9.3.42-0).

Root Cause

The deletion logic in src/libs/actions/Report/index.ts (lines 2560-2576) assumes whispers follow a fixed ID pattern:

• ACTIONABLE_MENTION_WHISPER has ID = parentCommentID + 1
• ACTIONABLE_REPORT_MENTION_WHISPER has ID = parentCommentID + 2

This works for the initial send scenario, but fails when a message is edited:

1. User sends message mentioning User A → whisper created at commentID + 1
2. User edits message to mention User B → NEW whisper created with a different ID (backend creates this on edit)
3. User deletes the message → code only looks at commentID + 1 and commentID + 2, missing the whisper from step 2

The backend correctly creates whispers on edit, but the frontend deletion logic does not account for this.

Verification

• The PR modifies src/libs/actions/Report/index.ts in the deleteReportComment function (lines 2549-2583)
• The code explicitly checks only two fixed IDs: reportActionID + 1 and reportActionID + 2
• The tests in the PR only cover single-whisper scenarios, not edit scenarios with multiple whispers

Suggested Fix

The deletion logic should iterate through all report actions and find whispers that reference the deleted comment as their parent (checking the whisper's originalMessage for parent linkage), rather than assuming fixed ID offsets.

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user sends a message with an @mention in a workspace chat (mentioning someone not in the room), Concierge creates an ACTIONABLEMENTIONWHISPER. If the user then edits the message to add a second @mention, a second whisper is created. When the user deletes the original message, only the first whisper disappears — the second whisper remains visible.

What is the root cause of that problem?

Both the frontend and backend locate whispers associated with a parent comment using fixed ID offsets rather than searching for all linked whispers:

• ACTIONABLE_MENTION_WHISPER is expected at parentCommentID + 1
• ACTIONABLE_REPORT_MENTION_WHISPER is expected at parentCommentID + 2

This convention is documented in src/libs/actions/Report/index.ts:2549-2553:

// Optimistically hide whispers associated with the deleted comment. We use the same conventions
// as the backend (UpdateReportComment.cpp) to locate the correct whisper(s):
//   - ACTIONABLE_MENTION_WHISPER has ID = parentCommentID + 1
//   - ACTIONABLE_REPORT_MENTION_WHISPER has ID = parentCommentID + 2

When a message is edited to add a new @mention, the backend creates a new whisper. But since parentCommentID + 1 is already occupied by the first whisper, the second whisper gets a completely different ID from the global action counter. This means:

1. On deletion (frontend optimistic): deleteReportComment() only checks IDs at parentID + 1 and parentID + 2 — misses the second whisper entirely.
2. On deletion (backend cascade): UpdateReportComment.cpp (Auth PR High-level design doc review (Expensifier / Graduate) - Implement TypeScript in New Expensify #19971) also uses the same +1/+2 convention — also misses the second whisper.
3. On visibility check: isResolvedActionableWhisper() uses the reverse arithmetic (whisperID - 1) to find the parent — the second whisper can't locate its parent this way either.

Additionally, the OriginalMessageActionableMentionWhisper type has no parentCommentID or reportActionID field to link back to its parent, unlike OriginalMessageActionableReportMentionWhisper which does store a reportActionID.

What changes do you think we should make in order to solve the problem?

This requires a coordinated backend + frontend fix:

Backend (Auth): When creating an ACTIONABLEMENTIONWHISPER during an edit, store the parent comment's reportActionID in the whisper's originalMessage (similar to how ACTIONABLE_REPORT_MENTION_WHISPER already does). Update the cascade deletion in UpdateReportComment.cpp to find and delete ALL ACTIONABLEMENTIONWHISPER actions that reference the deleted parent, not just the one at parentID + 1.

Frontend (App):

1. src/types/onyx/OriginalMessage.ts: Add a reportActionID field to OriginalMessageActionableMentionWhisper (matching the existing field on OriginalMessageActionableReportMentionWhisper).

2. src/libs/actions/Report/index.ts (deleteReportComment): After checking the fixed +1/+2 offsets, also iterate through the report's actions to find any additional ACTIONABLEMENTIONWHISPER actions whose originalMessage.reportActionID matches the deleted comment's ID, and add them to the optimistic deletion list.

3. src/libs/ReportActionsUtils.ts (isResolvedActionableWhisper): When checking if a whisper's parent is deleted, first try the originalMessage.reportActionID field (if present) to find the parent, falling back to the offset arithmetic for backward compatibility with older whispers that don't have the field.

What alternative solutions did you explore?

1. Frontend-only fix (iterate all actions): The frontend could scan all report actions to find whispers created around the same time as the parent, but without a stored parent reference this would be fragile and heuristic-based.

2. Always overwrite the whisper at +1 on edit: Instead of creating a new whisper, the backend could update the existing one at parentCommentID + 1 with the new invitee info. This avoids the ID mismatch but would lose the ability to track separate invite decisions for each mentioned user.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.