[$250] Email - Member invite with mention in room chat doesn't get the invite email

[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: v9.3.69-3
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/13176726/test-cases/41237090
Email or phone of affected tester (no customers): lattelover1412+090511@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win11/Chrome
App Component: Other

Action Performed:

1. Go to staging.new.expensify.com

2. Register as a new user to the app

3. Select “Manage my team’s expenses” and click Continue

4. Add a name for your business

5. Fill out a first & last name

6. Create a #room in the workspace

7. Click on the header of the room and navigate to Members

8. Click on the Invite button at the top

9. Invite an email address that does not have an expensify account (Should be a real account with an inbox that can receive the invite)

10. Open the Invitation mail box that was sent to the new user (step 9)

Expected Result:

After user invite email address that does not have an expensify account, a whisper message with option "invite to chat" displayed and invitation mail box should be sent then user able to proceed further steps.

Actual Result:

There is no whisper message "invite to chat" displayed and The member invited through the mentioned way doesn't get the invite email

Note: There is closed git #74788

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053715853772050379
• Upwork Job ID: 2053715853772050379
• Last Price Increase: 2026-05-25

Issue Owner

Current Issue Owner: @amyevans

[MelvinBot]

Issue Analysis

Root Cause: This is a backend issue. The App client correctly sends the InviteToRoom API command with the non-Expensify email — no client-side filtering excludes external accounts. The system message (ROOM_CHANGE_LOG.INVITE_TO_ROOM) and the invite email are both created entirely server-side by the InviteToRoom backend command, which appears to be failing silently for non-Expensify email addresses.

Note on the "invite to chat" whisper: The "invite to chat" whisper mentioned in the bug report is the ACTIONABLE_MENTION_WHISPER, which is a separate flow triggered by @mentioning a non-member in a message — it is not part of the Room > Members > Invite flow. The Room > Members > Invite flow should produce a ROOM_CHANGE_LOG.INVITE_TO_ROOM system message instead.

Recommended Fix: Investigate the backend InviteToRoom command handler to determine why it is not creating the system message or sending the invite email for non-Expensify (unregistered) email addresses. The client sends {reportID, inviteeEmails, accountIDList} — for unknown users, accountIDList contains client-generated optimistic IDs that the server should ignore in favor of looking up or creating accounts by email.

Investigation details

Client-side flow (verified — working correctly)

1. RoomInvitePage.tsx:191-214 — inviteUsers() builds an invitedEmailsToAccountIDs map. For unknown emails, accountID falls back to CONST.DEFAULT_NUMBER_ID (0) or an optimistic hash-based ID. For non-policy-expense-chat rooms, calls inviteToRoom().

2. Report/index.ts:4878-4901 — inviteToRoom() calls buildInviteToRoomOnyxData() then sends WRITE_COMMANDS.INVITE_TO_ROOM with parameters {reportID, inviteeEmails, accountIDList}.

3. Report/index.ts:4787-4791 — inviteeEmails contains ALL invited emails, but accountIDList is filtered via getNewAccountIDsAndLogins() to only include IDs for users not already in allPersonalDetails. For a single unknown email, both arrays align (length 1).

4. RoomInvitePage.tsx:112-121 — Excluded users are only Expensify system emails and existing participants. Non-Expensify external emails are not filtered out.

What the server should do

When InviteToRoom receives a request with an unregistered email:

1. Create/look up the account by email
2. Add the account as a participant to the room
3. Create a ROOM_CHANGE_LOG.INVITE_TO_ROOM report action (system message)
4. Send an invite email to the unregistered address

Steps 3 and 4 are not happening, indicating the backend command may be silently failing or skipping these steps for non-existent accounts.

Alternative explanation considered

Could the accountIDList mismatch cause the issue? For a single unknown email invite, inviteeEmails = ["email@example.com"] and accountIDList = ["<optimisticID>"] — both length 1, so no mismatch. The mismatch only occurs when mixing known + unknown users in one invite. This doesn't explain the bug for the single-user case described in the report.

---

This appears to be a backend/internal issue. A separate internal investigation is needed into the InviteToRoom backend command to determine why it silently fails for unregistered email addresses.

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[wildan-m]

Proposal

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

When a member is invited into a #room chat by mentioning their email in the chat (the email belongs to a person who does not yet have an Expensify account) and the inviter then clicks the "Invite to chat only" button on the resulting actionable mention whisper, the invited person is added to the room participants but never receives the welcome / invite email in their inbox. Inviting the same person from the room's Members page → Invite button sends the email correctly, so the two invite paths behave inconsistently. This is a regression that matches BrowserStack test case 41237090 and the previously closed #74788.

What is the root cause of that problem?

There are two server-side commands involved in inviting somebody to a room:

• INVITE_TO_ROOM, used by the Members page → Invite flow, which is called with an explicit inviteeEmails array and an accountIDList describing who is being added. The backend uses this explicit invitee list to fan out the invite email to each new login.

• RESOLVE_ACTIONABLE_MENTION_WHISPER, used when the inviter clicks "Invite to chat only" on the whisper produced by an unresolved mention. Look at how the frontend currently builds the parameters for this command:

App/src/libs/actions/Report/index.ts

Lines 5687 to 5692 in b7c38b1

	const parameters: ResolveActionableMentionWhisperParams = {
	reportActionID: reportAction.reportActionID,
	resolution,
	};
	API.write(WRITE_COMMANDS.RESOLVE_ACTIONABLE_MENTION_WHISPER, parameters, {optimisticData, failureData});

Only reportActionID and resolution are sent. There is no reportID and no inviteeEmails in the request body. The parameter type itself only allows those two fields:

App/src/libs/API/parameters/ResolveActionableMentionWhisperParams.ts

Lines 4 to 7 in b7c38b1

	type ResolveActionableMentionWhisperParams = {
	reportActionID: string;
	resolution: ValueOf<typeof CONST.REPORT.ACTIONABLE_MENTION_WHISPER_RESOLUTION> | ValueOf<typeof CONST.REPORT.ACTIONABLE_MENTION_INVITE_TO_SUBMIT_EXPENSE_CONFIRM_WHISPER>;
	};

As a result the backend has no explicit invitee data on this code path. It knows the whisper got resolved and it adds the mentioned users as participants of the room, but unlike INVITE_TO_ROOM it does not have the structured (reportID, inviteeEmails) pair it needs to enqueue the invite email job. The invited person therefore ends up inside the room without ever receiving the welcome / invite email — exactly the actual result reported in the issue.

The data the backend needs is already sitting on the report action itself. The actionable mention whisper's originalMessage carries the unresolved invitee logins under the inviteeEmails field, declared here:

App/src/types/onyx/OriginalMessage.ts

Lines 140 to 156 in b7c38b1

	/** Model of `actionable mention whisper` report action */
	type OriginalMessageActionableMentionWhisper = {
	/** Emails of users that aren't members of the room */
	inviteeEmails: string[];
	/** Account IDs of users that aren't members of the room */
	inviteeAccountIDs: number[];
	/** Decision on whether to invite users that were mentioned but aren't members or do nothing */
	resolution?: ValueOf<typeof CONST.REPORT.ACTIONABLE_MENTION_WHISPER_RESOLUTION> | null;
	/** Collection of accountIDs of users mentioned in message */
	whisperedTo?: number[];
	/** Timestamp of when the whisper was deleted (set by the backend when the parent comment is deleted) */
	deleted?: string | null;

So the frontend has everything it needs to mirror the parameters that INVITE_TO_ROOM sends; it just is not forwarding them.

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

Make the "Invite to chat only" path send the same identifying information that the Members page → Invite path sends, so the backend can trigger the invite email for the resolved whisper exactly the way it does for a direct Members page invite.

Concretely:

1. Extend the ResolveActionableMentionWhisperParams type to allow two additional optional fields: reportID and inviteeEmails: string[]. They are kept optional because the same command is also used for the "Do nothing" resolution and for the submit-expense confirm whisper, where invitee data is not needed.

2. In resolveActionableMentionWhisper inside src/libs/actions/Report/index.ts, when the resolution is CONST.REPORT.ACTIONABLE_MENTION_WHISPER_RESOLUTION.INVITE, read the originalMessage of the actionable mention whisper (the function already retrieves it for the optimistic participant update logic) and attach reportID plus originalMessage.inviteeEmails to the params object before calling API.write(WRITE_COMMANDS.RESOLVE_ACTIONABLE_MENTION_WHISPER, ...). For other resolutions (and for the confirm-whisper variant where the original message does not carry inviteeEmails) the new fields should be omitted, so behavior on those paths is unchanged.

After this change, when "Invite to chat only" is clicked the backend receives the same (reportID, inviteeEmails) pair it already receives from the Members page invite, which is what it needs to send the welcome / invite email to each newly added login. The new fields are additive and optional, so existing call sites and backend handling for the non-invite resolutions are not affected.

No string, navigation, or Onyx changes are needed; the optimistic participant update added by #88795 / #89363 already covers the in-app side of the flow, so this purely closes the email-sending half of the same fix.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90141-resolve-mention-invite-email?expand=1

What alternative solutions did you explore? (Optional)

Looking up the invitee data on the backend from the persisted report action keyed by reportActionID (so the frontend would not need to change). This would avoid touching the parameter type, but it pushes a frontend-known piece of data into a server-side lookup for no real benefit, increases coupling between the resolve command and the actionable whisper's storage layout, and is inconsistent with how the Members page invite already passes the same data explicitly. Forwarding the fields the frontend already has is the smaller, more symmetric change.

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When a user is invited to a room via the Members > Invite flow, the app should send an invite email to accounts that don't yet exist in Expensify, and display a whisper message with an "invite to chat" option. The issue referenced as "closed" (#74788) suggests this was previously fixed but has regressed.

The root cause is that when inviting a member to a room (as opposed to a workspace), the invitation logic likely calls the room-member invite action but does not correctly trigger the email invite flow for users who don't have an existing Expensify account. Specifically, the inviteMemberToReport (or equivalent) action likely calls the backend API to add the member to the report, but the code path that checks whether the invitee has an existing account and subsequently fires the invite email (and/or the whisper/nudge message) is either skipped or broken.

Looking at the invite member logic in:
https://github.com/Expensify/App/blob/main/src/libs/actions/Report.ts

and the invite page:
https://github.com/Expensify/App/blob/main/src/pages/RoomInvitePage.tsx

The RoomInvitePage collects the invitee list and calls Report.inviteToRoom. Inside that action, there is a check that should determine if the invited login has an existing account — if not, it should trigger the invite email. My investigation suggests the personalDetails lookup or the isCurrentUserInvited/account-existence check is evaluating incorrectly for brand-new email addresses, causing the email dispatch and whisper message to be silently skipped.

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

In src/libs/actions/Report.ts, the inviteToRoom function needs to correctly identify invitees who do not have existing Expensify accounts and ensure they are passed to the API in a way that triggers the invite email. The fix should ensure that for each invitee whose login does not resolve to an existing personalDetails entry (i.e., no accountID), we still proceed with sending the invite and not silently bail out.

A likely fix is in the participant/invitee mapping before the API call — when an invitee has no existing account, we must still include them with their login so the backend sends the invite email:

- const inviteeAccountIDs = inviteeLogins.map((login) => personalDetailsByLogin[login]?.accountID).filter(Boolean);
+ const inviteeAccountIDs = inviteeLogins
+     .map((login) => personalDetailsByLogin[login]?.accountID)
+     .filter((id): id is number => !!id);
+
+ const newUserLogins = inviteeLogins.filter((login) => !personalDetailsByLogin[login]?.accountID);

Then pass newUserLogins alongside inviteeAccountIDs to the API call so the backend can handle sending invite emails for accounts that don't yet exist:

  API.write(
      'InviteToRoom',
      {
          reportID,
          inviteeEmails: inviteeAccountIDs,
+         newInviteeEmails: newUserLogins,
      },
      ...
  );

Additionally, I'd check RoomInvitePage.tsx to ensure the whisper/nudge message is rendered when the API response comes back indicating new users were invited — this likely needs a corresponding Onyx key update or a check on the invitedEmailsToAccountIDs collection that also accounts for logins with no accountID yet.

What alternative solutions did you explore? (Optional)

One alternative would be to handle this entirely on the frontend by manually triggering a separate Report.sendEmailInvite style call for any login that doesn't resolve to an existing accountID. I'd prefer the approach above (passing new user logins to the existing API call) because it keeps the logic server-side and avoids a second network round-trip, which is how the workspace member invite flow already works.

[wildan-m]

Proposal updated — added compare branch with implementation.