[$250] Email - Row with a Concierge avatar and no text appears in the email between expense and message

[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: 9.3.78-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/13176724/test-cases/41237071
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: MacBook Air 15.7.4 Chrome, iPhone 15 iOS 26.4.3 Safari
App Component: Notifications

Action Performed:

1. Sign in to ND with a new account (User A), select "Submit expenses to my employer" purpose
2. Click FAB - Create expense - Scan - select a valid receipt
3. In the "To" field enter an email of a new account you can access, enter any description, create the expense
4. Navigate to the chat with a user from step 3 (User B), wait for the scan to finish
5. Click "Yeah!" green button on "Enjoying.." modal
6. Send a message in the conversation
7. As User B, open the email with the subject "Chat with User A", that contains the expense and the message (need to wait 10 min)

Expected Result:

Row with a Concierge avatar and no text does not appear in the email between expense and message

Actual Result:

Row with a Concierge avatar and no text appears in the email between expense and message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Retest.email.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7159033

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022057359775965998107
• Upwork Job ID: 2057359775965998107
• Last Price Increase: 2026-05-21

[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/dd44f6dd42dfb17dcd0db7b116f7774f9352afc78709a0b9473593cec58e3c83

[MelvinBot]

Proposal

What is the root cause of that problem?

The email notification system (backend, Web-Expensify) renders report actions from the DM and its associated IOU/transaction reports into the email body. When User A creates a scanned expense to User B, several Concierge-attributed system actions are created server-side (e.g., auto-submit SUBMITTED with harvesting: true, or SmartScan suggestion actions like CONCIERGE_CATEGORY_OPTIONS / CONCIERGE_DESCRIPTION_OPTIONS). These actions are correctly hidden in-app by shouldReportActionBeVisible, which filters out resolved actionable whispers, whispers targeted to other users, and system actions without renderable content. However, the backend email renderer lacks equivalent filtering — it includes these Concierge-attributed actions in the email, rendering them as rows with the Concierge avatar but no visible text content.

The most likely specific action is a SUBMITTED action with harvesting: true in the IOU report (which the frontend displays with Concierge as actor), or a CONCIERGE_CATEGORY_OPTIONS/CONCIERGE_DESCRIPTION_OPTIONS action created in the transaction thread after SmartScan completes. The email system inlines these into the DM notification without checking whether they have renderable message content.

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

The fix should be in the backend email notification renderer (Web-Expensify). The email builder should filter out report actions that either:

1. Have no renderable message text (empty message.text / message.html)
2. Are system/whisper action types that are only meaningful in the app UI (e.g., ACTIONABLE_* whispers, CONCIERGE_CATEGORY_OPTIONS, CONCIERGE_DESCRIPTION_OPTIONS, CONCIERGE_AUTO_MAP_MCC_GROUPS)
3. Are whispers targeted to users other than the email recipient (whisperedTo field)

This mirrors the filtering already done client-side in shouldReportActionBeVisible.

What alternative solutions did you explore?

An alternative is to add a general guard in the email template that skips rendering any row where the resolved message body is empty/whitespace-only. This is simpler and would catch any future action types with empty content, though it wouldn't address whispers being shown to the wrong recipient.

Investigation details

Reproduction flow analysis:

1. User A creates a scanned expense to User B (new DM created)
2. SmartScan processes the receipt, potentially creating CONCIERGE_CATEGORY_OPTIONS/CONCIERGE_DESCRIPTION_OPTIONS in the transaction thread
3. If auto-submit is triggered, a SUBMITTED action with harvesting: true is created in the IOU report — getReportActionActorAccountID resolves this to Concierge
4. User A sends a text message
5. Backend email job collects actions and renders them — the Concierge-attributed action appears between expense and message

Client-side filtering that the email lacks:

• Resolved actionable whispers are hidden (ReportActionsUtils.ts:1202)
• Whispers targeted to other users are hidden (ReportActionsUtils.ts:1231)
• Several action types render their display text entirely client-side (e.g., ACTIONABLE_MENTION_WHISPER via getActionableMentionWhisperMessage)

Note: The email rendering code is in Web-Expensify (inaccessible from this workspace), so the exact backend filtering gap cannot be pinpointed to a specific PHP file/line. The fix needs to be implemented in the backend notification rendering code.

---

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]

Proposal

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

When User B receives an email digest containing an expense and a follow-up message from User A, an extra row with a Concierge avatar and no text appears between the expense and the message. This spurious row makes the email look broken and confusing.

What is the root cause of that problem?

The extra row corresponds to the ACTIONABLE_MENTION_INVITE_TO_SUBMIT_EXPENSE_CONFIRM_WHISPER report action — the "Enjoying Expensify?" prompt that Concierge sends after an expense is created. This action is a whisper targeted to the submitting user (User A). In the app UI, shouldReportActionBeVisible in ReportActionsUtils.ts correctly hides it: either it is caught by isWhisperActionTargetedToOthers (line 1231) so User B never sees it, or once User A clicks "Yeah!" it is treated as a resolved actionable whisper (line 1254) and hidden. However, the server-side email digest renderer does not apply equivalent filtering for this action type. It includes the raw action in the email because its message array contains an empty or blank text fragment (the whisper body is only rendered via ConfirmWhisperContent in the app, not as a plain text string), so the email shows an avatar row with no visible text.

App/src/libs/ReportActionsUtils.ts

Lines 1231 to 1256 in d8c5117

	if (isWhisperActionTargetedToOthers(reportAction)) {
	return false;
	}
	if (isPendingRemove(reportAction) && !reportAction.childVisibleActionCount) {
	return false;
	}
	if (
	(isActionableReportMentionWhisper(reportAction) ||
	isActionableJoinRequestPendingReportAction(reportAction) ||
	isActionableMentionWhisper(reportAction) ||
	isActionableCardFraudAlert(reportAction)) &&
	!canUserPerformWriteAction
	) {
	return false;
	}
	if (isTripPreview(reportAction) || isTravelUpdate(reportAction)) {
	return true;
	}
	// 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 changes do you think we should make in order to solve the problem?

The fix should ensure the ACTIONABLE_MENTION_INVITE_TO_SUBMIT_EXPENSE_CONFIRM_WHISPER action is never included in the email digest. Because the email renderer is server-side and outside this repo, the best lever available in the App codebase is to make sure the action's whisperedTo field is always populated with only the actor's account ID, so the server-side email renderer can apply the same "whisper targeted to others" exclusion it presumably already uses for other whisper types. If the whisperedTo field is missing or empty on this action type (which would explain why the server-side filter misses it), the fix is to populate it correctly when the action is created. The place to verify and patch this is in the optimistic action construction for ACTIONABLE_MENTION_INVITE_TO_SUBMIT_EXPENSE_CONFIRM_WHISPER — confirm that whisperedTo is set to [actorAccountID] so the server renderer excludes it from digests sent to other participants, matching how other whisper actions are excluded.

App/src/libs/ReportActionsUtils.ts

Lines 609 to 632 in d8c5117

	if (!(originalMessage && typeof originalMessage === 'object' && 'whisperedTo' in originalMessage) && !(message && typeof message === 'object' && 'whisperedTo' in message)) {
	return [];
	}
	if (message !== null && !Array.isArray(message) && typeof message === 'object' && 'whisperedTo' in message) {
	return message?.whisperedTo ?? [];
	}
	if (originalMessage && typeof originalMessage === 'object' && 'whisperedTo' in originalMessage) {
	return originalMessage?.whisperedTo ?? [];
	}
	if (typeof originalMessage !== 'object') {
	Log.info('Original message is not an object for reportAction: ', true, {
	reportActionID: reportAction?.reportActionID,
	actionName: reportAction?.actionName,
	});
	}
	return [];
	}
	function isWhisperAction(reportAction: OnyxInputOrEntry<ReportAction>): boolean {
	return getWhisperedTo(reportAction).length > 0;

What alternative solutions did you explore? (Optional)

N/A

[yusufdeveloper2903]

Issue: #91267
Title: mail-Row with a Concierge avatar and no text appears in the email between expense and message
Labels: Daily, Bug
Created: 2026-05-21 (first mover — only applause-bot comment present)
Main SHA analyzed: e8c6aa8

NOTE (chat, not posted): This is fundamentally a SERVER-SIDE (Web-Expensify) email-digest
bug. App repo has NO email/digest rendering and does NOT author the empty whisper. Flagged
to user; user explicitly asked to write the proposal anyway. Proposal is an honest server-side
RCA with App code as evidence/model. No honest App-side diff exists.

Mechanism:

• Blank row = a Concierge actionable whisper (interactive prompt between expense and message).
• "Chat with User A" email rendered server-side (Web-Expensify), not App (10-min batch delay).
• Actionable whispers carry no plain-text body: label computed CLIENT-SIDE at render via
  getActionableMentionWhisperMessage (src/libs/ReportActionsUtils.ts:2429-2448), returns ''.
• Contrast: buildOptimisticActionableTrackExpenseWhisper stores html/text inline
  (src/libs/ReportUtils.ts:7539-7556) — that whisper has a body.
• Server email can't run client computation -> empty content cell + Concierge avatar = blank row.
• These whispers are interactive + account-private (whisperedToAccountIDs) -> shouldn't be in a digest.

Fix (Web-Expensify digest renderer): skip actionable-whisper actions, mirroring the App predicate
isActionableWhisper (src/libs/ReportActionsUtils.ts:1126-1140). Alt: author a static text fallback
in message.html at creation (track-expense whisper pattern) — also server-side for this flow.

App-side: confirmed NONE. EmailUtils.ts = address-string only; money-request flow only references
actionableWhisperReportActionID, never builds the whisper (server-authored).

---

Proposal

What is the root cause of that problem?

The blank row is a Concierge actionable whisper (the interactive prompt that sits between the expense and the message), and the "Chat with User A" email is rendered server-side by the digest builder, not by the App.

Actionable whispers don't carry a plain‑text body — their label is computed client‑side at render time, so message[].html is effectively empty. See getActionableMentionWhisperMessage, which builds the string on the fly from inviteeAccountIDs + translate and returns '' when there's nothing to compute:

App/src/libs/ReportActionsUtils.ts

Lines 2429 to 2448 in e8c6aa8

	return reportActions.some((action) => action.actionName === CONST.REPORT.ACTIONS.TYPE.IOU && action.actorAccountID === currentAccountID && !isDeletedAction(action));
	}
	/**
	* Constructs a message for an actionable mention whisper report action.
	* @param reportAction
	* @returns the actionable mention whisper message.
	*/
	function getActionableMentionWhisperMessage(translate: LocalizedTranslate, reportAction: OnyxEntry<ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_MENTION_WHISPER>>): string {
	if (!reportAction) {
	return '';
	}
	const originalMessage = getOriginalMessage(reportAction);
	const targetAccountIDs: number[] = originalMessage?.inviteeAccountIDs ?? [];
	const personalDetails = getPersonalDetailsByIDs({accountIDs: targetAccountIDs, currentUserAccountID: 0});
	const personalDetailsMap = createPersonalDetailsLookupByAccountID(personalDetails);
	const mentionElements = targetAccountIDs.map((accountID): string => {
	const personalDetail = personalDetailsMap[accountID];
	const displayName = getEffectiveDisplayName(formatPhoneNumber, personalDetail);

Contrast this with the one actionable whisper that does store an inline body — buildOptimisticActionableTrackExpenseWhisper writes html/text directly into message[]:

App/src/libs/ReportUtils.ts

Lines 7539 to 7556 in e8c6aa8

	actionName: CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_TRACK_EXPENSE_WHISPER,
	actorAccountID,
	avatar: getDefaultAvatarURL({accountID: actorAccountID, accountEmail: targetEmail}),
	created: DateUtils.addMillisecondsFromDateTime(currentTime, 1),
	lastModified: DateUtils.addMillisecondsFromDateTime(currentTime, 1),
	message: [
	{
	html: CONST.ACTIONABLE_TRACK_EXPENSE_WHISPER_MESSAGE,
	text: CONST.ACTIONABLE_TRACK_EXPENSE_WHISPER_MESSAGE,
	whisperedTo: [],
	type: CONST.REPORT.MESSAGE.TYPE.COMMENT,
	},
	],
	originalMessage: {
	lastModified: DateUtils.addMillisecondsFromDateTime(currentTime, 1),
	transactionID,
	},
	person: [

In the app this is fine: the client renders the label/buttons. But the digest email has no client to run that computation, so for the bodyless whisper it emits only the Concierge avatar and an empty content cell — the blank row. These whispers are also interactive and account‑private (whisperedToAccountIDs), which is precisely the class of action a shared digest email should not be rendering at all.

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

The fix belongs in the Web‑Expensify email‑digest renderer: skip actionable‑whisper actions when building the digest, mirroring the predicate the App already uses to classify them:

App/src/libs/ReportActionsUtils.ts

Lines 1126 to 1140 in e8c6aa8

	}
	function isActionableWhisper(
	reportAction: OnyxEntry<ReportAction>,
	): reportAction is ReportAction<
	| typeof CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_MENTION_WHISPER
	| typeof CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_TRACK_EXPENSE_WHISPER
	| typeof CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_REPORT_MENTION_WHISPER
	| typeof CONST.REPORT.ACTIONS.TYPE.ACTIONABLE_MENTION_INVITE_TO_SUBMIT_EXPENSE_CONFIRM_WHISPER
	> {
	return (
	isActionableMentionWhisper(reportAction) ||
	isActionableTrackExpense(reportAction) ||
	isActionableReportMentionWhisper(reportAction) ||
	isActionableMentionInviteToSubmitExpenseConfirmWhisper(reportAction)

Conceptually, the digest loop should drop these before rendering a row:

- // render every visible report action into the email
+ // actionable whispers are interactive + account-private and carry no email body — skip them
+ if (isActionableWhisper(action)) {
+     continue;
+ }

If product instead wants these to appear in the digest, the parallel fix is to give the whisper a static text fallback in message[].html at authoring time — exactly the pattern buildOptimisticActionableTrackExpenseWhisper already uses (lines linked above). For this submit‑to‑recipient flow the whisper is authored server‑side, so that change would also live in Web‑Expensify.

What alternative solutions did you explore? (Optional)

• Generic guard: have the digest skip any report action whose resolved body is empty/whitespace. Broader safety net, but riskier — it could swallow other legitimately‑bodyless system actions, so I'd prefer the targeted whisper skip.
• App‑side change: I confirmed there isn't an honest one. The App has no email/digest rendering (src/libs/EmailUtils.ts is only address‑string handling), and it doesn't author this whisper (the money‑request flow only references actionableWhisperReportActionID; the whisper itself is created server‑side). So nothing in src/ can change what the email shows.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When User A submits the expense to User B, Concierge posts an actionable whisper into the A↔B chat (the App models these as ACTIONABLEMENTIONWHISPER / ACTIONABLEMENTIONINVITETOSUBMITEXPENSECONFIRMWHISPER — see isActionableMentionInviteToSubmitExpenseConfirmWhisper and the inline ConfirmWhisperContent renderer). That whisper is scoped to a subset of participants via whisperedTo — here, only User A, who resolves it with the inline "Confirm" button.

In the app this works correctly. getWhisperedTo reads the action's whisperedTo, and shouldReportActionBeVisible drops the action outright as soon as isWhisperActionTargetedToOthers is true. So in NewDot, User B never sees the whisper row at all.

The "Chat with User A" email digest is rendered server-side (OldDot) and does not apply that whisperedTo filter. It still emits a row for the whisper action, but because User B is not one of its whisperedTo targets the whisper's text is withheld — leaving a row with only the Concierge avatar and no text, sitting between the expense and User A's message. The app and the email disagree: the app removes whispers targeted at other users, the email keeps an empty shell of them.

This is the only mechanism that explains the exact symptom — completely absent in-app, but an empty (not just hidden) row in the email: a regular hidden action would still render its text in the digest; only a whisper-targeted-to-others renders as a textless row.

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

The email digest must enforce the same whisper-visibility rule the app already enforces: a report action that is a whisper not targeted to the recipient should be excluded entirely, not rendered as an empty row.

The canonical logic already exists in the App (getWhisperedTo / isWhisperActionTargetedToOthers); the digest's per-recipient action loop should reuse it with the email recipient's accountID:

  // For each report action while building <recipient>'s email digest:
+ // A whisper not addressed to this recipient must not produce a row at all,
+ // mirroring shouldReportActionBeVisible() / isWhisperActionTargetedToOthers() in NewDot.
+ const whisperedTo = getWhisperedTo(reportAction);
+ if (whisperedTo.length > 0 && !whisperedTo.includes(recipientAccountID)) {
+     continue;
+ }

Concretely:

1. Add the guard above to the report-email digest builder so whispers targeted at other accounts are skipped per recipient.
2. Re-run the regression test (BrowserStack TC 41237071) to confirm the empty Concierge row no longer appears between the expense and the message.

This fixes the cause (the whisperedTo mismatch) rather than the symptom (empty text). NewDot already behaves correctly via shouldReportActionBeVisible, so the App side needs no change — it is the reference implementation; the change lands in the OldDot/Web-Expensify digest renderer.

What alternative solutions did you explore? (Optional)

• Skip any action whose message renders empty in the digest. Rejected — this targets the symptom, not the cause. An action can be legitimately empty for other reasons, so this would both mask future bugs and risk dropping valid rows; the precise signal for "this row should not exist for this recipient" is whisperedTo, not text emptiness.
• Stop scoping the whisper with whisperedTo so it has no restricted audience. Rejected — the whisper is correctly restricted to User A (only A should confirm it, and B should not see it in-app). Broadening its audience to paper over the email would regress the in-app experience and surface a confirmation prompt to the wrong user.

[melvin-bot]

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

[melvin-bot]

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