[$250] Native share - "Email not found", "Report no longer exists" error up after sharing attachment

[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.98-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/13176721/test-cases/41236967
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Other

Action Performed:

1. Share a photo from device gallery to Expensify app.
2. Go to Share tab.
3. Enter email of non-existing user and tap on the email.
4. Tap Share.

Expected Result:

The attachment will be shared to the user without issue.

Actual Result:

The attachment cannot be shared to the user.
"Email not found" and "Report no longer exists" error up.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7170524_1780494466262.Screen_Recording_20260603_214400_Expensify.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022062178103200463226
• Upwork Job ID: 2062178103200463226
• Last Price Increase: 2026-06-03

Issue Owner

Current Issue Owner: @justinpersaud

[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/2e52f97f78168678400ae36debfa671a1d781c6b9af657974e6dc7e5805503c8

[MelvinBot]

Issue Analysis

Conclusion (medium confidence): Both messages — "Email not found" and "Report no longer exists" — are returned by the backend API, not generated by the App. Neither string exists anywhere in the App source. The App frontend correctly detects the new (unregistered) user and builds the optimistic chat, but handleShare fires the attachment write without waiting for the report to be created, which produces the cascade of two errors.

What's verified (from code)

• The unknown-user path is taken correctly. For a non-existing email, the selected participant carries a truthy optimistic accountID and reportID: undefined, so the optimistic-report branch in ShareTabParticipantsSelector.tsx:26-46 runs and an optimistic chat report (with the typed email as the participant login) is saved as a draft.
• The attachment write is not gated on report creation. In ShareDetailsPage.tsx:143-173, handleShare calls openReport(...) and then immediately addAttachmentWithComment(...) against the same optimistic reportID — there is no await/.then between them.
• Both error strings are backend-originated. "Email not found" and "Report no longer exists" do not appear in the App repo, so they are surfaced from the OpenReport / AddAttachment API responses.

Most likely mechanism (hypothesis — not yet log-confirmed)

1. OpenReport, called with the unregistered email, returns "Email not found" (the account is not created for this share path).
2. Because the attachment write isn't awaited, AddAttachment then targets a report the backend never persisted → "Report no longer exists".

Why this needs an internal check before a fix is locked in

The primary failure ("Email not found") is returned by the OpenReport API for an unregistered email — i.e. it sits at the API boundary, outside the App repo. Confirming whether that rejection is expected (and why the normal "start a new chat with a new email" flow can invite an unregistered user but this share path cannot) requires production logs / backend access that aren't available here. An internal engineer should confirm the OpenReport behavior for this flow via logs before implementing.

App-side improvement (partial, implementable now)

Gate the attachment write on a successful OpenReport (await/.then) so a failed report creation doesn't cascade into a second, confusing "Report no longer exists" error. ⚠️ This alone will not make sharing to a brand-new user succeed if OpenReport keeps rejecting the email with "Email not found" — that part lives at the API boundary and needs the internal check above.

Investigation details & evidence

Frontend branch is correct (no report 0 navigation bug): For a "user to invite" row, getUserToInviteOption generates a deterministic optimistic accountID (hash of the email) and the typed email as login; the resulting participant has reportID: undefined. In ShareTabParticipantsSelector.tsx, reportID = participant?.reportID ?? CONST.DEFAULT_NUMBER_ID → 0, and if (accountID && !reportID) → true, so an optimistic report is created and the typed email is stored via saveUnknownUserDetails. The login is re-injected into the display option via the unknown-user branch in OptionsListUtils.getReportDisplayOption, so openReport is called with participants: [{ login: <typedEmail>, accountID: <optimisticAccountID> }].

The race: ShareDetailsPage.handleShare issues openReport(... newReportObject: report) and addAttachmentWithComment({report, ...}) back-to-back, then navigates to ROUTES.REPORT_WITH_ID. If OpenReport fails, the optimistic report is torn down, so the user also lands on the "Hmm... it's not here" page.

Not reproducible from code alone: whether OpenReport should succeed (auto-invite the new email) in this path. Production logs for the OpenReport request from this flow are needed to confirm which command returns which error.

---

Next Steps for Contributor+ team:
To accept the App-side mitigation: @MelvinBot implement [this](https://github.com/Expensify/App/blob/dd0f6b462ad71463337e67a523bd5d33e76098aa/src/pages/Share/ShareDetailsPage.tsx#L143-L173) to gate the attachment write on OpenReport success (partial fix only — see caveat above).
Before doing so: an internal engineer should confirm via OpenReport logs whether the "Email not found" rejection for an unregistered email is the true root cause, since that part is outside the App repo.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting this analysis.

[neerajbachani]

proposal

[kamronbek04]

Proposal

What is the root cause of that problem?

Sharing a native attachment to a brand-new email goes through the "unknown user" branch of the Share tab. In ShareTab.onSelectRow, when the selected option has an accountID but no reportID (the userToInvite case), the app saves the option as SHARE_UNKNOWN_USER_DETAILS, builds an optimistic chat with getOptimisticChatReport, saves it as a report draft, and navigates to the details page:

https://github.com/Expensify/App/blob/main/src/pages/Share/ShareTab.tsx#L135-L152

That accountID is not a real account. For a user who doesn't exist yet, getUserToInviteOption mints a client-side hash of the typed email as the optimistic accountID and only sets login to the actual email:

https://github.com/Expensify/App/blob/main/src/libs/OptionsListUtils/index.ts#L1964-L1982

The break happens on share. ShareDetailsPage.handleShare detects the draft and calls openReport, building the participant list from displayReport.participantsList and forwarding both the login and that fabricated accountID:

https://github.com/Expensify/App/blob/main/src/pages/Share/ShareDetailsPage.tsx#L143-L158

openReport turns the participants straight into the API payload — emailList from the logins and accountIDList from the accountIDs:

https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1465-L1467
https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1571-L1581

So OpenReport is sent with accountIDList=<generateAccountID(email)>, a hashed integer the server has never issued. The backend can't resolve that accountID to a real user ("Email not found"), and the optimistic chat creation it was supposed to back is rejected and rolled back ("Report no longer exists"). Contrast the canonical new-DM flow, navigateToAndOpenReport, which builds participants with buildParticipantInfoFromLogins(userLogins) — {login, accountID: undefined} — so openReport's accountIDList filter drops the undefined and the server gets only the email to resolve and create:

https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L2266-L2275
https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1356-L1361

Share is the one new-chat entry point that forwards the client-fabricated accountID instead of letting the server resolve the email, so it's the only one that fails for never-seen users.

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

Stop sending the optimistic (client-generated) accountID to OpenReport, matching the contract every other new-chat path already follows: send the login for a not-yet-existing user and let the backend resolve/create the account. The accountID should only ride along when it maps to a real personal detail. personalDetails is already in scope in handleShare (it's passed to openReport on the next line), so the gate is a one-line lookup:

                     participants:
                         displayReport.participantsList
                             ?.filter((u) => u.accountID !== personalDetail.accountID)
-                            .map((u) => ({
-                                login: u.login ?? '',
-                                accountID: u.accountID,
-                            })) ?? [],
+                            .map((u) => {
+                                // For a user who doesn't exist yet, the accountID is a client-side hash
+                                // (generateAccountID) the server can't map. Forwarding it makes OpenReport
+                                // fail with "Email not found" and rolls the optimistic chat back
+                                // ("Report no longer exists"). Send only the login and let the backend
+                                // resolve/create the account — same contract as buildParticipantInfoFromLogins.
+                                const hasRealAccount = !!u.accountID && !!personalDetails?.[u.accountID];
+                                return {
+                                    login: u.login ?? '',
+                                    accountID: hasRealAccount ? u.accountID : undefined,
+                                };
+                            }) ?? [],

The optimistic Onyx data is untouched — getOptimisticChatReport still keys the local chat and its optimistic personal details off the generated accountID for immediate display, exactly as openReport's own optimistic-personal-details block does via getAccountIDsByLogins. The only thing that changes is the API payload: the server now receives a resolvable email instead of a phantom accountID, creates the user and chat, and the subsequent addAttachmentWithComment lands on a real report.

This keeps the existing-user-without-a-chat sub-case working too: those options carry a real, loaded accountID, so hasRealAccount stays true and their accountID is still sent (the navigateToAndOpenReportWithAccountIDs pattern). Scope boundary — no change to the text-share path, to openReport itself, or to the optimistic report/draft construction. Reviewers should watch one thing: confirm that after the server responds, the chat reconciles onto the real accountID and no duplicate/optimistic personal detail keyed by the old hash lingers in the DM header (this is the same reconciliation the normal new-DM flow relies on, so it should hold).

Verification approach

On staging, share a photo from the gallery into Expensify, go to the Share tab, type an email that has never been used before, tap it, and tap Share. After the fix the chat is created and the attachment posts with no red brick road — versus current behavior where "Email not found" and "Report no longer exists" appear and the chat fails to materialize. Re-test with an existing user that you've never DM'd to confirm that path (real accountID forwarded) still works.

What alternative solutions did you explore?

Unconditionally dropping the accountID (accountID: undefined for every participant) and relying purely on emailList. It fixes the reported case and is the simplest diff, but it also strips the real accountID from the existing-user-without-a-chat path, which currently works by accountID. Resolving a known user by email instead of their accountID is a needless behavior change on a working path and risks edge cases with phone-number logins, so I gated on personalDetails presence instead to change only the broken case.

I also considered fixing it inside openReport — filtering out accountIDs that have no real personal detail before building accountIDList. I rejected it because openReport is called from dozens of sites that legitimately pass optimistic accountIDs (e.g. account-ID-based DM creation), and silently dropping them there could regress flows that depend on the optimistic accountID reaching the server. The fault is Share forwarding an accountID it shouldn't, so the fix belongs at that call site.

[yusufdeveloper2903]

Proposal

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

When sharing a file from the device gallery to the Expensify app and choosing a recipient who is not yet an Expensify user (a brand‑new email), tapping Share fails with backend errors Email not found and Report no longer exists instead of creating the chat and sending the attachment.

What is the root cause of that problem?

The Share flow sends the recipient's optimistic (fake) accountID to OpenReport, and the backend cannot resolve it for an account that doesn't exist yet.

When you pick a non‑existing user, ShareTab takes the userToInvite branch in onSelectRow and builds an optimistic draft chat:

App/src/pages/Share/ShareTab.tsx

Lines 135 to 152 in 2d8b35e

	const onSelectRow = (item: OptionData) => {
	let reportID = item?.reportID ?? CONST.DEFAULT_NUMBER_ID;
	const accountID = item?.accountID;
	if (accountID && !reportID) {
	saveUnknownUserDetails(item);
	const optimisticReport = getOptimisticChatReport(accountID, currentUserAccountID);
	reportID = optimisticReport.reportID;
	setSelectedReportID(reportID);
	saveReportDraft(reportID, optimisticReport).then(() => {
	Navigation.navigate(ROUTES.SHARE_DETAILS.getRoute(reportID.toString()));
	});
	} else {
	clearUnknownUserDetails();
	setSelectedReportID(reportID);
	Navigation.navigate(ROUTES.SHARE_DETAILS.getRoute(reportID.toString()));
	}
	};

That recipient comes from getUserToInviteOption, which assigns a client‑side hashed accountID (generateAccountID(searchValue)) and flags the option as optimistic:

App/src/libs/OptionsListUtils/index.ts

Lines 2029 to 2047 in 2d8b35e

	// Generates an optimistic account ID for new users not yet saved in Onyx
	const optimisticAccountID = generateAccountID(searchValue);
	const personalDetailsExtended = {
	...personalDetails,
	[optimisticAccountID]: {
	accountID: optimisticAccountID,
	login: searchValue,
	},
	};
	const userToInvite = createOption({
	accountIDs: [optimisticAccountID],
	personalDetails: personalDetailsExtended,
	report: null,
	privateIsArchived: undefined,
	config: {showChatPreviewLine},
	visibleReportActionsData,
	});
	userToInvite.isOptimisticAccount = true;
	userToInvite.login = searchValue;

On the details screen, handleShare then calls openReport, mapping the participant to both login and that optimistic accountID:

App/src/pages/Share/ShareDetailsPage.tsx

Lines 143 to 158 in 2d8b35e

	if (isDraft) {
	openReport({
	reportID: report.reportID,
	introSelected,
	participants:
	displayReport.participantsList
	?.filter((u) => u.accountID !== personalDetail.accountID)
	.map((u) => ({
	login: u.login ?? '',
	accountID: u.accountID,
	})) ?? [],
	personalDetails,
	newReportObject: report,
	betas,
	});
	}

Inside openReport, the participant accountIDs are collected and forwarded to the server as accountIDList:

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

Lines 1473 to 1475 in 2d8b35e

	const participantLoginList = participants.map((p) => p.login).filter((login) => !!login);
	// TODO: allPersonalDetails fallback should be removed in follow-up PRs https://github.com/Expensify/App/issues/73656
	const participantAccountIDList = participants.map((p) => p.accountID).filter((id): id is number => id !== undefined);

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

Lines 1579 to 1589 in 2d8b35e

	const parameters: OpenReportParams = {
	reportID,
	reportActionID,
	emailList: participantLoginList ? participantLoginList.join(',') : '',
	accountIDList: participantAccountIDList ? participantAccountIDList.join(',') : '',
	parentReportActionID,
	transactionID: transaction?.transactionID,
	includePartiallySetupBankAccounts: true,
	useLastUnreadReportAction: true,
	includeLockedBankAccounts: true,
	};

For a non‑existing user that accountID is a fabricated hash that does not exist on the backend, so OpenReport fails with Email not found; the chat is never created, and the addAttachmentWithComment call that fires right after it then fails with Report no longer exists. For an existing user the very same code sends a real accountID, the backend resolves it, and everything works — which is exactly why the bug only reproduces with new users.

The canonical "start a new chat" path proves this: navigateToAndOpenReport → createAndOpenNewOptimisticChat deliberately builds participants with buildParticipantInfoFromLogins(userLogins), i.e. login only, no accountID, so OpenReport resolves/creates the user purely from the email:

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

Lines 2275 to 2285 in 2d8b35e

	// We pass newReportObject to force chat creation on the server.
	openReport({
	reportID: fallbackChat.reportID,
	introSelected,
	reportActionID: '',
	participants: buildParticipantInfoFromLogins(userLogins),
	personalDetails,
	newReportObject: fallbackChat,
	isSelfTourViewed,
	betas,
	});

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

Lines 1367 to 1372 in 2d8b35e

	function buildParticipantInfoFromLogins(logins: string[], accountIDs?: number[]): ParticipantInfo[] {
	return logins.map((login, index) => ({
	login,
	accountID: accountIDs?.[index],
	}));
	}

The Share flow diverges from that convention by passing the optimistic accountID, which is the root cause.

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

Stop sending the optimistic accountID to OpenReport from the Share flow, and let the backend resolve/create the participant from the email — exactly like buildParticipantInfoFromLogins does for every other new‑chat path.

In src/pages/Share/ShareDetailsPage.tsx:

                         participants:
                             displayReport.participantsList
                                 ?.filter((u) => u.accountID !== personalDetail.accountID)
                                 .map((u) => ({
                                     login: u.login ?? '',
-                                    accountID: u.accountID,
                                 })) ?? [],

Dropping accountID is safe for existing users too: openReport already re‑derives participant accountIDs from the login list (via getAccountIDsByLogins) when building optimistic personal details, so the optimistic UI is unaffected — and this is precisely what the standard new‑chat flow already does.

Edge cases:

• Offline: the optimistic draft chat + attachment still render immediately; the corrected OpenReport/AddAttachment requests flush from the queue on reconnect and now succeed for new users.
• Existing user with no prior chat: still goes through this same branch and keeps working (resolved by email).
• Platforms: the fix is in shared JS, so it covers Android/iOS/web; the report is Android per the regression run.

What alternative solutions did you explore? (Optional)

• Only strip the accountID when the participant is optimistic (accountID: u.isOptimisticAccount ? undefined : u.accountID). It works, but OptionData.participantsList is typed as PersonalDetails[] (no isOptimisticAccount), so it needs reading the flag from the SHARE_UNKNOWN_USER_DETAILS Onyx value. Unconditionally passing login only is simpler and matches the existing buildParticipantInfoFromLogins precedent.
• Make the backend tolerate unknown accountIDs in accountIDList — wrong layer; the frontend is sending data it shouldn't, and every other new‑chat path already avoids this.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

In ShareDetailsPage, when you share to a user that doesn't have a chat yet, the share goes through the "draft report" branch and calls openReport with the participant's client-generated optimistic accountID alongside the typed email:

https://github.com/Expensify/App/blob/main/src/pages/Share/ShareDetailsPage.tsx#L143-L158

openReport({
    reportID: report.reportID,
    introSelected,
    participants:
        displayReport.participantsList
            ?.filter((u) => u.accountID !== personalDetail.accountID)
            .map((u) => ({
                login: u.login ?? '',
                accountID: u.accountID, // 👈 this is an OPTIMISTIC accountID for unknown users
            })) ?? [],
    personalDetails,
    newReportObject: report,
    betas,
});

The accountID here comes from userToInvite in OptionsListUtils.getUserToInviteOption, which assigns a deterministic client-side fake ID for non-existing users:

https://github.com/Expensify/App/blob/main/src/libs/OptionsListUtils/index.ts#L2029-L2046

That accountID is then preserved through saveUnknownUserDetails (which writes the raw OptionData to SHARE_UNKNOWN_USER_DETAILS), and getReportDisplayOption rehydrates it into displayReport.participantsList here:

https://github.com/Expensify/App/blob/main/src/libs/OptionsListUtils/index.ts#L1311-L1314

Inside openReport, participants are split into two strings sent to the backend — emailList and accountIDList:

https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1473-L1475
https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1579-L1589

So the server receives emailList=<typed email> and accountIDList=<optimistic ID that doesn't exist server-side>. The backend rejects the request with "Email not found" / "Report no longer exists" because the accountID it's told to use doesn't match any user. Compare with the working "create a new chat with a non-existing user" path (navigateToAndOpenReport), which builds participants via buildParticipantInfoFromLogins and intentionally passes only logins — accountIDs are left undefined so the backend resolves the user from the email:

https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1367-L1372
https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L2263-L2285

This was a regression from the openReport signature migration — the original ShareDetailsPage implementation passed userLogins.map(u => u.login ?? '') (login-only), but when the API was reshaped to {login, accountID}[], the call site was updated mechanically and started including the optimistic accountID.

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

I think we should mirror what navigateToAndOpenReport does and stop sending the optimistic accountID to the server in the share-to-new-user path. The openReport flow already re-derives optimistic accountIDs from logins for its optimistic personal details (https://github.com/Expensify/App/blob/main/src/libs/actions/Report/index.ts#L1768-L1784), so dropping it from the API parameters costs nothing locally and lets the backend resolve / create the user by email as it does in every other new-chat flow.

The whole fix is a one-line change in src/pages/Share/ShareDetailsPage.tsx inside handleShare:

                 openReport({
                     reportID: report.reportID,
                     introSelected,
                     participants:
                         displayReport.participantsList
                             ?.filter((u) => u.accountID !== personalDetail.accountID)
-                            .map((u) => ({
-                                login: u.login ?? '',
-                                accountID: u.accountID,
-                            })) ?? [],
+                            .map((u) => ({login: u.login ?? ''})) ?? [],
                     personalDetails,
                     newReportObject: report,
                     betas,
                 });

That's all that's needed for the bug. The control flow here is only reached when isDraft is true, which in ShareTab.onSelectRow only happens when the user selected an entry without an existing reportID — i.e. either a brand-new email (optimistic accountID, the bug case) or a known personalDetail without a chat yet (real accountID). For the second case, dropping the accountID is still safe: the backend resolves the real user from the email and reconciles with the optimistic reportID, identical to how navigateToAndOpenReport handles "you've never chatted with this contact" today.

What alternative solutions did you explore? (Optional)

• Only strip the accountID when it's optimistic (u.isOptimisticAccount). This is more surgical, but isOptimisticAccount isn't part of the Participant type that backs SHARE_UNKNOWN_USER_DETAILS (https://github.com/Expensify/App/blob/main/src/ONYXKEYS.ts#L1615), and getReportDisplayOption doesn't carry the flag through participantsList explicitly — so doing this would require either widening Participant/OptionData or adding an extra personalDetails lookup. The win over "just drop accountID" is small because in this code path we always create the chat optimistically client-side, so the backend already needs to do the lookup-or-create-by-email step regardless.

• Route the share through navigateToAndOpenReport instead of calling openReport directly. That would centralize "create a 1:1 chat" logic, but it also runs getChatByParticipants + navigation side-effects that fight with the share-flow navigation (Navigation.revealRouteBeforeDismissingModal happens immediately after, and we still need addAttachmentWithComment queued on the same optimistic reportID). The minimal one-line fix above achieves the same correctness without restructuring the share navigation contract.

• Have SubmitDetailsPage carry the same fix. It already routes new-user submits through requestMoney/trackExpense which build their own participants, so it's not affected by this exact bug — no change needed there.

[mukhrr]

Proposal

What is the root cause of that problem?

This is Android native-share specific because the repro enters the app through Android’s share intent and uses the native share flow (ShareRootPage → ShareTab → ShareDetailsPage) instead of the normal in-app attachment picker.

When selecting a non-existing email in the Share tab, we save the selected invite row as unknownUserDetails and create a local draft chat with an optimistic account ID:

App/src/pages/Share/ShareTab.tsx

Lines 120 to 130 in d01f4e0

	const onSelectRow = (item: OptionData) => {
	let reportID = item?.reportID ?? CONST.DEFAULT_NUMBER_ID;
	const accountID = item?.accountID;
	if (accountID && !reportID) {
	saveUnknownUserDetails(item);
	const optimisticReport = getOptimisticChatReport(accountID, currentUserAccountID);
	reportID = optimisticReport.reportID;
	setSelectedReportID(reportID);
	saveReportDraft(reportID, optimisticReport).then(() => {
	Navigation.navigate(ROUTES.SHARE_DETAILS.getRoute(reportID.toString()));

That account ID is generated from the typed email for local UI purposes:

App/src/libs/OptionsListUtils/index.ts

Lines 2029 to 2047 in d01f4e0

	// Generates an optimistic account ID for new users not yet saved in Onyx
	const optimisticAccountID = generateAccountID(searchValue);
	const personalDetailsExtended = {
	...personalDetails,
	[optimisticAccountID]: {
	accountID: optimisticAccountID,
	login: searchValue,
	},
	};
	const userToInvite = createOption({
	accountIDs: [optimisticAccountID],
	personalDetails: personalDetailsExtended,
	report: null,
	privateIsArchived: undefined,
	config: {showChatPreviewLine},
	visibleReportActionsData,
	});
	userToInvite.isOptimisticAccount = true;
	userToInvite.login = searchValue;

On the details page, getReportDisplayOption() uses unknownUserDetails to build participantsList, preserving that optimistic account ID:

App/src/libs/OptionsListUtils/index.ts

Lines 1311 to 1314 in d01f4e0

	} else if (unknownUserDetails) {
	option.text = unknownUserDetails.text ?? unknownUserDetails.login;
	option.alternateText = unknownUserDetails.login;
	option.participantsList = [{...unknownUserDetails, displayName: unknownUserDetails.login, accountID: unknownUserDetails.accountID ?? CONST.DEFAULT_NUMBER_ID}];

Then ShareDetailsPage opens the draft report using displayReport.participantsList, so it passes both the email and the generated account ID to openReport():

App/src/pages/Share/ShareDetailsPage.tsx

Lines 143 to 157 in d01f4e0

	if (isDraft) {
	openReport({
	reportID: report.reportID,
	introSelected,
	participants:
	displayReport.participantsList
	?.filter((u) => u.accountID !== personalDetail.accountID)
	.map((u) => ({
	login: u.login ?? '',
	accountID: u.accountID,
	})) ?? [],
	personalDetails,
	newReportObject: report,
	betas,
	});

openReport() converts all participant account IDs into accountIDList, so the generated optimistic ID is sent to the backend as if it were a real account ID:

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

Lines 1473 to 1475 in d01f4e0

	const participantLoginList = participants.map((p) => p.login).filter((login) => !!login);
	// TODO: allPersonalDetails fallback should be removed in follow-up PRs https://github.com/Expensify/App/issues/73656
	const participantAccountIDList = participants.map((p) => p.accountID).filter((id): id is number => id !== undefined);

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

Lines 1579 to 1584 in d01f4e0

	const parameters: OpenReportParams = {
	reportID,
	reportActionID,
	emailList: participantLoginList ? participantLoginList.join(',') : '',
	accountIDList: participantAccountIDList ? participantAccountIDList.join(',') : '',
	parentReportActionID,

The backend rejects that recipient, causing “Email not found”. Since the attachment action is queued immediately after OpenReport, it targets an optimistic report that was never created on the server, causing “Report no longer exists”.

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

Normalize native-share draft report participants before calling openReport.

For SHARE_UNKNOWN_USER_DETAILS, we should treat the recipient as invite-only. Its generated account ID is local-only and must not be sent in accountIDList. Instead, open the report using the email login only, matching the existing chat creation pattern where unknown users are resolved by emailList.

Add a helper in ShareDetailsPage and use it for draft report creation:

+const getShareOpenReportParticipants = () => {
+    if (unknownUserDetails?.login) {
+        return [{login: unknownUserDetails.login}];
+    }
+
+    return (
+        displayReport.participantsList
+            ?.filter((participant) => participant.accountID !== personalDetail.accountID)
+            .map((participant) => ({
+                login: participant.login ?? '',
+                accountID: participant.accountID,
+            })) ?? []
+    );
+};
+
+const openShareDraftReport = () => {
+    if (!isDraft) {
+        return;
+    }
+
+    openReport({
+        reportID: report.reportID,
+        introSelected,
+        participants: getShareOpenReportParticipants(),
+        personalDetails,
+        newReportObject: report,
+        betas,
+    });
+};

Then replace the inline draft-open logic in the attachment share path:

- if (isDraft) {
-     openReport({
-         reportID: report.reportID,
-         introSelected,
-         participants:
-             displayReport.participantsList
-                 ?.filter((u) => u.accountID !== personalDetail.accountID)
-                 .map((u) => ({
-                     login: u.login ?? '',
-                     accountID: u.accountID,
-                 })) ?? [],
-         personalDetails,
-         newReportObject: report,
-         betas,
-     });
- }
+ openShareDraftReport();

This makes openReport() send emailList: new.user@example.com and an empty accountIDList for non-existing recipients. Existing recipients still pass their real account IDs.

We should also add a focused test that covers Android native share unknown recipients:

• Set unknownUserDetails with a generated account ID and login.
• Share into a draft report.
• Assert OpenReport receives the email in emailList.
• Assert the generated optimistic account ID is not sent in accountIDList.

What alternative solutions did you explore? (Optional)

We could filter optimistic account IDs globally inside openReport(), but that function is shared by many report opening and creation flows. A global filter has a larger blast radius.

The safer fix is scoped to native share, where unknownUserDetails explicitly tells us the recipient is invite-only and the account ID is only a local optimistic value.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.