[$250] Chat - Whisper message disappears after mentioning second user

[applause-bot]

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: v9.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176685/test-cases/41236620
Email or phone of affected tester (no customers): htad26+gbnd@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10 / Chrome, iOS 26.3 / iPhone 13
App Component: Chat Report View

Action Performed:

1. Create a Public Room if needed
2. Mention a user who is not a member of the room
3. Send another mention of a different user that is not part of the room

Expected Result:

The system message for the first mention and for the second mention exists

Actual Result:

The whisper message for the first mention disappears

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7161149_1779522242465.bandicam_2026-05-23_10-43-16-550.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7161149

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058766420823684467
• Upwork Job ID: 2058766420823684467
• Last Price Increase: 2026-06-01

Issue Owner

Current Issue Owner: @akinwale

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/f5704b19e6d4816b59265d5219e26df3ad9e6d9096ee4838a863d68c22f7dc91

[MelvinBot]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-28 03:16:51 UTC.

Proposal

What is the root cause of that problem?

This is a regression introduced by PR #89450. The backend overloads originalMessage.deleted on actionable mention whispers for two different purposes: (1) cascade delete when the parent ADD_COMMENT is removed, and (2) one-per-room cleanup when a newer whisper is created. PR #82720 originally added a parent-comment check inside isResolvedActionableWhisper to distinguish these cases. PR #89450 removed that check — and the regression test protecting it — so isResolvedActionableWhisper now treats both cases identically, hiding the first whisper when the second arrives.

Mention whispers are already skipped from the visibleReportActions derived value cache via shouldSkipCachingAction, so the parent-check only ever ran at render time where reading report actions is safe. The refactor removed a check it never needed to remove for the derived value's purity.

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

Restore the parent-comment check in isResolvedActionableWhisper. When originalMessage.deleted is set but resolution is not, and the action is an ACTIONABLE_MENTION_WHISPER or ACTIONABLE_REPORT_MENTION_WHISPER, look up the parent action using getReportAction. Return false (keep whisper visible) if the parent exists and is not deleted — that is the backend's one-per-room cleanup case. Return true (hide whisper) only when the parent is actually deleted or absent — the genuine cascade-delete case. Re-add the regression test removed by PR #89450.

What alternative solutions did you explore? (Optional)

A middleware-based approach (sanitizing the API response before it reaches Onyx) was considered but rejected — the deleted flag disambiguation is a property of the stored action's context (parent alive vs. deleted), not the response batch, and the render-visibility layer is the natural place for this check.

---

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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 04:26:59 UTC.

Proposal

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

When a user @mentions a non-member of a public room and then @mentions a second non-member, the whisper "Heads up, @user isn't a member of this room" for the FIRST mention disappears from the chat.

What is the root cause of that problem?

When a new actionable mention whisper is created, the backend marks any previously unresolved mention whisper in the same room as originalMessage.deleted (the "one-per-user cleanup" rule). On the client, isResolvedActionableWhisper treats any whisper with deleted set as resolved and shouldReportActionBeVisible then filters it out — so the older whisper disappears even though its parent ADD_COMMENT is still present.

This used to be handled correctly: isResolvedActionableWhisper distinguished cascade deletion (parent comment deleted → whisper should hide) from the one-per-user cleanup (parent still exists → whisper should stay visible). That branch was removed in commit 829358c5ff4 (PR #89450 "Refactor: simplified isResolvedActionableWhisper to remove dependency from ONYXKEYS.COLLECTION.REPORT_ACTIONS Onyx data"), and the dedicated regression test "should keep ACTIONABLE_MENTION_WHISPER visible when deleted is set but parent comment is not deleted" (added in commit f7600a56ec0) was removed in the same refactor.

The current implementation that lost the parent check:

App/src/libs/ReportActionsUtils.ts

Lines 1153 to 1169 in de3e3bf

	function isResolvedActionableWhisper(reportAction: OnyxEntry<ReportAction>): boolean {
	const originalMessage = getOriginalMessage(reportAction);
	if (!originalMessage || typeof originalMessage !== 'object') {
	return false;
	}
	const resolution = 'resolution' in originalMessage ? originalMessage?.resolution : null;
	if (resolution) {
	return true;
	}
	const deleted = 'deleted' in originalMessage ? originalMessage?.deleted : null;
	if (!deleted) {
	return false;
	}
	return true;
	}

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

Restore the parent-comment check inside isResolvedActionableWhisper in src/libs/ReportActionsUtils.ts. For an ACTIONABLE_MENTION_WHISPER (or ACTIONABLE_REPORT_MENTION_WHISPER) whose originalMessage.deleted is set but resolution is not, look up the parent action — preferring originalMessage.parentReportActionID when present and falling back to reportActionID − 1 (or − 2 for the report-mention variant) — and return false when the parent is still alive (not deleted). Only return true if the parent itself was deleted, which is the genuine cascade-delete case. To keep this off the hot path for the visibility derived value, pass the report's actions into isResolvedActionableWhisper from shouldReportActionBeVisible / isReportActionVisible rather than reading the Onyx collection inside the helper (this was the original shape before PR #89450). Also re-add the regression test from commit f7600a56ec0 so this can't silently break again.

The call site that needs to forward the report's actions:

App/src/libs/ReportActionsUtils.ts

Lines 1255 to 1258 in de3e3bf

	// If action is actionable whisper and resolved by user, then we don't want to render anything
	if (isActionableWhisper(reportAction) && isResolvedActionableWhisper(reportAction)) {
	return false;
	}

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @QichenZhu (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058766420823684467

[lxyct825-ops]

Proposal

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

[$250] Chat - Whisper message disappears after mentioning second user

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

(See Sentry issue for full stack trace)

The root cause is that the application code at the crash site does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!