[$250] Workspace chat membership is not updated when reports are submitted to a different approver

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Reproduction blocked, PR reverted)
Reproducible in production?: Needs reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @iwiznia @garrettmknight
Slack conversation (hyperlinked to channel name): #QA

Action Performed:

1. Create a Submit workspace with: Submitter, Approver 1, Approver 2.
2. As Submitter, create an expense/report and submit it to Approver 1.
3. Verify Approver 1 is added to the submitter's Workspace chat.
4. As Submitter, create another expense/report and submit it to Approver 2.
5. Check the membership of the submitter's Workspace chat.

Expected Result:

Approver 1 is removed from the submitter's Workspace chat while retaining access to the first report they approved.
Approver 2 is added to the submitter's Workspace chat.
The Workspace chat reflects only the current approver relationship.

Actual Result:

Approver 1 remains in the submitter's Workspace chat after the second report is submitted to Approver 2.
Workspace chat membership is not updated to reflect the new approver.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022070143582018056301
• Upwork Job ID: 2070143582018056301
• Last Price Increase: 2026-06-25

[MelvinBot]

Issue Analysis

Root Cause: This isn't reproducible right now because the App-side "submit to a chosen approver" feature was reverted. PR #87998 "[Submit] Submit button with manager email prompt" (merged 2026-06-19) added the popover that lets a submitter pick which approver to submit to and forwarded that selection to the backend on submit. It was rolled back by PR #94333 "[CP Staging] Revert: Submit button with manager email prompt" (merged 2026-06-23). This issue was filed 2026-06-25 — two days after the revert — which is exactly why it's marked "Reproduction blocked, PR reverted."

After the revert, submitReport resolves the manager solely via getSubmitReportManagerAccountID(policy, expenseReport) and sends only reportID / managerAccountID / reportActionID — it no longer carries the chosen approver.

The actual "add new approver / remove previous approver" membership swap on the submitter's Workspace chat is handled backend-side (the SubmitReport command's effect on policyExpenseChat membership), not in App. App's submit flow never mutates workspace‑chat participants.

⚠️ The fix requires changes outside the App repo. Re-landing the App feature alone won't fix the symptom — the "Approver 1 remains after submitting to Approver 2" behavior is a backend membership-management gap. This needs a separate internal/backend investigation of how SubmitReport updates the submitter's workspace‑chat membership, plus coordination with the re‑land of #87998. An internal engineer with backend repo access should pick this up.

Investigation details

• Reverted feature PR: #87998 — merge ca3e2d5. Added the ReportSubmitTo popover and the approver-resolution chain (managerEmail param + optimistic managerID resolution) in submitReport.
• Revert PR: #94333 — merge a7895e2. Stripped managerEmail from SubmitReportParams and removed the approver-resolution logic, reverting managerID to getSubmitReportManagerAccountID(policy, expenseReport).
• Current App state: A grep for participants / policyExpenseChat in ReportWorkflow.ts shows the submit path never adds or removes the approver from the workspace chat — consistent with the membership swap being server-side.
• Timeline: feature 2026-06-19 → revert 2026-06-23 → issue filed 2026-06-25.

Alternative considered: That App was supposed to optimistically add/remove the approver participant itself. Ruled out — even before the revert, App only forwarded the chosen approver; no participant add/remove ever existed in the submit path, so the membership update is necessarily backend-driven.

Confidence: High on the App-side cause (the revert) and that the membership swap is backend-driven. The exact backend PR/handler couldn't be enumerated here (private repos).

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this analysis. Implementation is not something I can draft here since the fix lives in a backend repo — please escalate to an internal engineer.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The "members" of the submitter's Workspace chat are rendered only from report.participants of that policyExpenseChat report. getParticipantsList → getParticipantsAccountIDsForDisplay simply iterates report?.participants and returns the account IDs, with no derivation from the policy approver chain or from the submitted reports:

• App/src/libs/ReportUtils.ts

  Lines 3589 to 3631 in d41e19c

  	function getParticipantsAccountIDsForDisplay(
  	report: OnyxEntry<Report>,
  	shouldExcludeHidden = false,
  	shouldExcludeDeleted = false,
  	shouldForceExcludeCurrentUser = false,
  	reportMetadataParam?: OnyxEntry<ReportMetadata>,
  	personalDetails: OnyxEntry<PersonalDetailsList> = allPersonalDetails,
  	): number[] {
  	const reportParticipants = report?.participants ?? {};
  	const reportMetadata = reportMetadataParam ?? getReportMetadata(report?.reportID);
  	let participantsEntries = Object.entries(reportParticipants);
  	// We should not show participants that have an optimistic entry with the same login in the personal details
  	const nonOptimisticLoginMap: Record<string, boolean | undefined> = {};
  	for (const entry of participantsEntries) {
  	const [accountID] = entry;
  	const personalDetail = personalDetails?.[accountID];
  	if (personalDetail?.login && !personalDetail.isOptimisticPersonalDetail) {
  	nonOptimisticLoginMap[personalDetail.login] = true;
  	}
  	}
  	participantsEntries = participantsEntries.filter(([accountID]) => {
  	const personalDetail = personalDetails?.[accountID];
  	if (personalDetail?.login && personalDetail.isOptimisticPersonalDetail) {
  	return !nonOptimisticLoginMap[personalDetail.login];
  	}
  	return true;
  	});
  	let participantsIds = participantsEntries.map(([accountID]) => Number(accountID));
  	// For 1:1 chat, we don't want to include the current user as a participant in order to not mark 1:1 chats as having multiple participants
  	// For system chat, we want to display Expensify as the only participant
  	const shouldExcludeCurrentUser = isOneOnOneChat(report) || isSystemChat(report) || shouldForceExcludeCurrentUser;
  	if (shouldExcludeCurrentUser || shouldExcludeHidden || shouldExcludeDeleted) {
  	participantsIds = excludeParticipantsForDisplay(participantsIds, reportParticipants, reportMetadata, {shouldExcludeHidden, shouldExcludeDeleted, shouldExcludeCurrentUser});
  	}
  	return participantsIds.filter((accountID) => isNumber(accountID));
  	}

• App/src/libs/ReportUtils.ts

  Lines 3633 to 3635 in d41e19c

  	function getParticipantsList(report: Report, personalDetails: OnyxEntry<PersonalDetailsList>, isRoomMembersList = false, reportMetadata: OnyxEntry<ReportMetadata> = undefined): number[] {
  	const shouldExcludeHiddenParticipants = !isGroupChat(report) && !isInvoiceReport(report) && !isMoneyRequestReport(report) && !isMoneyRequest(report) && !isPolicyExpenseChat(report);
  	const chatParticipants = getParticipantsAccountIDsForDisplay(report, isRoomMembersList || shouldExcludeHiddenParticipants, false, false, reportMetadata, personalDetails);

So whoever is a member of the Workspace chat is exactly whatever the backend has written into policyExpenseChat.participants. The App never adds or removes an approver there.

Confirming that on the write side: submitting a report (submitReport) builds optimisticData/successData/failureData that only touch the expense report (stateNum/statusNum/managerID/nextStep), its report actions, next step and metadata — and the parent iouReportID. It never writes to the workspace chat's participants (the chat keyed by expenseReport.chatReportID):

• optimistic report merge (only managerID/status/nextStep, no participants):

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1395 to 1462 in d41e19c

  	if (!isSubmitAndClosePolicy) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
  	value: {
  	...expenseReport,
  	...(shouldAddOptimisticSubmitAction
  	? {
  	lastMessageText: getReportActionText(optimisticSubmittedReportAction),
  	lastMessageHtml: getReportActionHtml(optimisticSubmittedReportAction),
  	}
  	: {}),
  	// For DEW policies, don't optimistically update managerID, stateNum, statusNum, or nextStep
  	// because DEW determines the actual workflow on the backend
  	...(isDEWPolicy
  	? {}
  	: {
  	managerID,
  	stateNum: CONST.REPORT.STATE_NUM.SUBMITTED,
  	statusNum: CONST.REPORT.STATUS_NUM.SUBMITTED,
  	nextStep: optimisticNextStep,
  	pendingFields: {
  	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
  	},
  	}),
  	},
  	});
  	} else {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
  	value: {
  	...expenseReport,
  	// For DEW policies, don't optimistically update stateNum, statusNum, or nextStep
  	...(isDEWPolicy
  	? {}
  	: {
  	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
  	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
  	nextStep: optimisticNextStep,
  	pendingFields: {
  	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
  	},
  	}),
  	},
  	});
  	}
  	if (!isDEWPolicy) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
  	value: optimisticNextStepDeprecated,
  	});
  	}
  	if (parentReport?.reportID) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${parentReport.reportID}`,
  	value: {
  	...parentReport,
  	// In case its a manager who force submitted the report, they are the next user who needs to take an action
  	hasOutstandingChildRequest: isCurrentUserManager,
  	iouReportID: null,
  	},
  	});
  	}

• success/failure data (same keys, no participant mutation):

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1474 to 1579 in d41e19c

  	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [];
  	if (!isDEWPolicy) {
  	successData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
  	value: {
  	pendingFields: {
  	nextStep: null,
  	},
  	},
  	});
  	}
  	if (shouldAddOptimisticSubmitAction) {
  	successData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
  	value: {
  	[optimisticSubmittedReportAction.reportActionID]: {
  	pendingAction: null,
  	},
  	},
  	});
  	}
  	if (isDEWPolicy) {
  	successData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
  	value: {
  	pendingExpenseAction: null,
  	},
  	});
  	}
  	const failureData: Array<
  	OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.NEXT_STEP | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>
  	> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
  	value: {
  	statusNum: expenseReport.statusNum,
  	stateNum: expenseReport.stateNum,
  	managerID: expenseReport.managerID,
  	...(isDEWPolicy
  	? {}
  	: {
  	nextStep: expenseReport.nextStep ?? null,
  	pendingFields: {
  	nextStep: null,
  	},
  	}),
  	},
  	},
  	];
  	if (shouldAddOptimisticSubmitAction) {
  	if (isDEWPolicy) {
  	// delete the optimistic SUBMITTED action as The backend creates a DEW_SUBMIT_FAILED action instead.
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
  	value: {
  	[optimisticSubmittedReportAction.reportActionID]: null,
  	},
  	});
  	} else {
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
  	value: {
  	[optimisticSubmittedReportAction.reportActionID]: {
  	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other'),
  	},
  	},
  	});
  	}
  	}
  	if (isDEWPolicy) {
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
  	value: {
  	pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.SUBMIT_FAILED,
  	},
  	});
  	}
  	if (!isDEWPolicy) {
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
  	value: expenseReportCurrentNextStepDeprecated ?? null,
  	});
  	}
  	if (parentReport?.reportID) {
  	failureData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${parentReport.reportID}`,
  	value: {
  	hasOutstandingChildRequest: parentReport.hasOutstandingChildRequest,
  	iouReportID: expenseReport.reportID,
  	},
  	});
  	}

• the SubmitReport command itself only sends reportID, managerAccountID, reportActionID:

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1581 to 1588 in d41e19c

  	const parameters: SubmitReportParams = {
  	reportID: expenseReport.reportID,
  	managerAccountID: managerID,
  	reportActionID: optimisticSubmittedReportAction.reportActionID,
  	};
  	onSubmitted?.();
  	API.write(WRITE_COMMANDS.SUBMIT_REPORT, parameters, {optimisticData, successData, failureData});

The sibling approver-mutation flows behave identically — they only set managerID on the expense report and never re-shape the workspace chat membership:

• assignReportToMe (take control):

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1628 to 1639 in d41e19c

  	const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.NEXT_STEP> = {
  	optimisticData: [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`,
  	value: {
  	managerID: accountID,
  	nextStep: optimisticNextStep,
  	pendingFields: {
  	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
  	},
  	},

• addReportApprover (change approver):

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1742 to 1754 in d41e19c

  	const onyxData: OnyxData<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.NEXT_STEP> = {
  	optimisticData: [
  	{
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${report.reportID}`,
  	value: {
  	managerID: newApproverAccountID,
  	nextStep: optimisticNextStep,
  	pendingFields: {
  	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
  	},
  	},
  	},

So the add of Approver 1, and the expected remove of Approver 1 / add of Approver 2 on the second submission, are entirely produced by the backend SubmitReport response writing policyExpenseChat.participants. The App renders whatever participant set it receives and removes a member only when the backend merges participants: {[approver1AccountID]: null}.

So: Workspace-chat membership = report.participants (ReportUtils) → App's submitReport never writes chat participants, only the expense report's managerID → membership is 100% backend-driven → when the 2nd report is submitted to Approver 2, the backend SubmitReport adds Approver 2 but does not prune Approver 1 from the previous Workspace chat → Approver 1 lingers. This is a backend (Auth SubmitReport) issue, not a client one — consistent with the issue being "Reproduction blocked, PR reverted" and not reproducible against production. There is no client code path that could currently produce or fix this membership transition.

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

The source of truth for Workspace-chat membership is the backend SubmitReport command, which must, when a submitter's report is routed to a new approver, prune the previous approver from that submitter's policyExpenseChat.participants (while leaving their access to the already-approved report intact), and add the new approver. The App already consumes this correctly: getParticipantsAccountIDsForDisplay will drop Approver 1 the moment the backend merges participants: {[approver1AccountID]: null} for that chat — no client change is needed to reflect it.

If we additionally want the transition to be reflected optimistically (so the membership flips before the round-trip), the minimal, reuse-first client change is to extend submitReport's optimisticData/failureData to merge the chat report's participants (the report keyed by expenseReport.chatReportID, same key already used by the approve flow at

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 531 to 548 in d41e19c

	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	// TODO: https://github.com/Expensify/App/issues/66512
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	getAllTransactionViolations(),
	undefined,
	),
	},
	});
	}

), adding the new managerID and nulling the previously-submitted approver. But the persistent/server state must still come from the backend, so this is purely cosmetic — the real fix belongs to SubmitReport.

Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Deriving Workspace-chat members on the client from the policy approver chain + each report's managerID instead of from report.participants. Rejected: it would diverge from how every other chat computes membership (getParticipantsList), reimplement approver-visibility rules the backend already owns, and break the "Approver 1 retains access to the first report they approved" requirement, which is exactly the per-report vs per-chat distinction the backend is positioned to make.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-25 13:57:23 UTC.

Proposal

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

When a submitter submits a second report to a different approver, the submitter's Workspace chat keeps the previous approver as a member instead of reflecting the current approver relationship (the new approver is added, but the old one is never removed).

What is the root cause of that problem?

Workspace-chat membership is keyed off the report's approver (managerID), but none of the submit/approve flows reconcile the parent Workspace chat (policyExpenseChat) participants when the approver changes.

In submitReport we compute the new approver in managerID:

App/src/libs/actions/IOU/ReportWorkflow.ts

Line 1336 in 323e7a3

const managerID = getSubmitReportManagerAccountID(policy, expenseReport);

…but the only optimistic update we push to the parent Workspace chat sets hasOutstandingChildRequest and iouReportID — it never touches participants:

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 1451 to 1462 in 323e7a3

	if (parentReport?.reportID) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${parentReport.reportID}`,
	value: {
	...parentReport,
	// In case its a manager who force submitted the report, they are the next user who needs to take an action
	hasOutstandingChildRequest: isCurrentUserManager,
	iouReportID: null,
	},
	});
	}

approveMoneyRequest has the same gap — it updates hasOutstandingChildRequest on the chat but not participants:

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 530 to 547 in 323e7a3

	if (chatReport) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	// TODO: https://github.com/Expensify/App/issues/66512
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	getAllTransactionViolations(),
	undefined,
	),
	},
	});
	}

So once Approver 1 has been added to the Workspace chat (from the first submission), submitting a later report to Approver 2 adds nothing/leaves Approver 1 in place, and the membership goes stale until the backend happens to recompute it.

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

In submitReport, when we build the optimistic update for the parent Workspace chat, reconcile its participants against the approvers that still have an outstanding report in that chat. The membership set should be: every managerID of a non-closed expense report whose parent is this Workspace chat. We add the ones missing and null out the ones that are no longer a current approver.

Concretely, where we already push the parentReport update (ReportWorkflow.ts#L1451-L1462), compute the reconciled participants and include them:

const outstandingApproverIDs = getOutstandingApproverIDsForChat(parentReport.reportID, managerID);
const currentParticipantIDs = Object.keys(parentReport.participants ?? {}).map(Number);

const participantsUpdate: Participants = {
    ...buildParticipantsFromAccountIDs(outstandingApproverIDs),
};
// Remove approvers that no longer manage an outstanding report in this chat
currentParticipantIDs
    .filter((id) => !outstandingApproverIDs.includes(id) && isPreviousApprover(id))
    .forEach((id) => (participantsUpdate[id] = null));

…and add participants: participantsUpdate to the existing parentReport MERGE value. buildParticipantsFromAccountIDs already produces the right shape ({notificationPreference: 'always'}):

App/src/libs/ReportUtils.ts

Lines 3660 to 3667 in 323e7a3

	}
	function buildParticipantsFromAccountIDs(accountIDs: number[]): Participants {
	const finalParticipants: Participants = {};
	return accountIDs.reduce((participants, accountID) => {
	// eslint-disable-next-line no-param-reassign
	participants[accountID] = {notificationPreference: CONST.REPORT.NOTIFICATION_PREFERENCE.ALWAYS};
	return participants;

We then mirror the same reconciliation in approveMoneyRequest (ReportWorkflow.ts#L530-L547) so the chat updates when approval moves down the chain, and add the inverse in failureData to restore the prior participants on error.

Note: the "remove Approver 1 from the Workspace chat while retaining their access to the first report" semantics are ultimately enforced by the backend (the report thread stays accessible independent of chat membership); the change above keeps NewDot's optimistic membership in sync so it no longer shows the stale approver. We can confirm the exact set returned by the BE in the PR phase and align the success data accordingly.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add a unit test around submitReport: given a Workspace chat that already lists Approver 1 as a participant (from a first report), submitting a second report to Approver 2 should optimistically add Approver 2 and remove Approver 1 from the chat participants. Add the symmetric case where Approver 1 still has an outstanding report — they must stay a member.

What alternative solutions did you explore? (Optional)

A simpler, add-only optimistic update — add the new managerID to the chat participants in submitReport/approveMoneyRequest and let the backend drop the stale approver. This is smaller but leaves a window where both approvers appear in the chat until the BE response lands, so the reconciliation approach above gives a correct optimistic state.

[mukhrr]

Proposal

What is the root cause of that problem?

The App already computes the correct approver at submit time. submitReport() calls getSubmitReportManagerAccountID() and sends that value as managerAccountID to SubmitReport.

Current code:

• getSubmitReportManagerAccountID() chooses the policy route when reliable, otherwise preserves an existing valid manager:
  

  App/src/libs/PolicyUtils.ts

  Lines 1573 to 1589 in 02a3327

  	function getSubmitReportManagerAccountID(policy: OnyxEntry<Policy>, expenseReport: OnyxEntry<Report>): number | undefined {
  	const ownerAccountID = expenseReport?.ownerAccountID ?? CONST.DEFAULT_NUMBER_ID;
  	const existingManagerID = expenseReport?.managerID;
  	const approvalRules = policy?.rules?.approvalRules;
  	const ruleApprover = !isSubmitAndClose(policy) && approvalRules?.length ? getFirstRuleApprover(approvalRules, expenseReport) : '';
  	const submitToAccountID = ruleApprover ? (getAccountIDsByLogins([ruleApprover]).at(0) ?? -1) : getManagerAccountID(policy, expenseReport);
  	const isValidSubmitToAccountID = isValidAccountRoute(submitToAccountID);
  	const isValidExistingManagerID = isValidAccountRoute(existingManagerID ?? CONST.DEFAULT_NUMBER_ID) && existingManagerID !== ownerAccountID;
  	const employeeLogin = getLoginByAccountID(ownerAccountID) ?? '';
  	const hasReliablePolicyRoute =
  	([CONST.POLICY.APPROVAL_MODE.OPTIONAL, CONST.POLICY.APPROVAL_MODE.BASIC] as Array<ValueOf<typeof CONST.POLICY.APPROVAL_MODE>>).includes(getApprovalWorkflow(policy)) ||
  	!!ruleApprover ||
  	!!policy?.employeeList?.[employeeLogin];
  	if (hasReliablePolicyRoute && isValidSubmitToAccountID) {
  	return submitToAccountID;
  	}

• submitReport() writes the computed manager to the expense report optimistic data:
  

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1336 to 1418 in 02a3327

  	const managerID = getSubmitReportManagerAccountID(policy, expenseReport);
  	const optimisticNextStepApproverID = !isSubmitAndClosePolicy && managerID !== undefined && isValidAccountRoute(managerID) ? managerID : undefined;
  	const isCurrentUserManager = currentUserAccountIDParam === managerID;
  	const optimisticSubmittedReportAction = buildOptimisticSubmittedReportAction(
  	expenseReport?.total ?? 0,
  	expenseReport.currency ?? '',
  	expenseReport.reportID,
  	adminAccountID,
  	policy?.approvalMode,
  	delegateEmail,
  	);
  	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
  	// For DEW policies, only add optimistic submit action when offline
  	const shouldAddOptimisticSubmitAction = !isDEWPolicy || getIsOffline();
  	// buildOptimisticNextStep is used in parallel
  	const optimisticNextStepDeprecated = isDEWPolicy
  	? null
  	: buildNextStepNew({
  	report: expenseReport,
  	predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
  	policy,
  	currentUserAccountIDParam,
  	currentUserEmailParam,
  	hasViolations,
  	isASAPSubmitBetaEnabled,
  	isUnapprove: true,
  	bypassNextApproverID: optimisticNextStepApproverID,
  	});
  	const optimisticNextStep = isDEWPolicy
  	? null
  	: buildOptimisticNextStep({
  	report: expenseReport,
  	predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
  	policy,
  	currentUserAccountIDParam,
  	currentUserEmailParam,
  	hasViolations,
  	isASAPSubmitBetaEnabled,
  	isUnapprove: true,
  	bypassNextApproverID: optimisticNextStepApproverID,
  	});
  	const optimisticData: Array<
  	OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.NEXT_STEP | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>
  	> = [];
  	if (shouldAddOptimisticSubmitAction) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
  	value: {
  	[optimisticSubmittedReportAction.reportActionID]: {
  	...(optimisticSubmittedReportAction as OnyxTypes.ReportAction),
  	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
  	},
  	},
  	});
  	}
  	if (!isSubmitAndClosePolicy) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
  	value: {
  	...expenseReport,
  	...(shouldAddOptimisticSubmitAction
  	? {
  	lastMessageText: getReportActionText(optimisticSubmittedReportAction),
  	lastMessageHtml: getReportActionHtml(optimisticSubmittedReportAction),
  	}
  	: {}),
  	// For DEW policies, don't optimistically update managerID, stateNum, statusNum, or nextStep
  	// because DEW determines the actual workflow on the backend
  	...(isDEWPolicy
  	? {}
  	: {
  	managerID,
  	stateNum: CONST.REPORT.STATE_NUM.SUBMITTED,
  	statusNum: CONST.REPORT.STATUS_NUM.SUBMITTED,
  	nextStep: optimisticNextStep,
  	pendingFields: {
  	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
  	},

• The API payload only sends reportID, managerAccountID, and reportActionID:
  

  App/src/libs/actions/IOU/ReportWorkflow.ts

  Lines 1581 to 1588 in 02a3327

  	const parameters: SubmitReportParams = {
  	reportID: expenseReport.reportID,
  	managerAccountID: managerID,
  	reportActionID: optimisticSubmittedReportAction.reportActionID,
  	};
  	onSubmitted?.();
  	API.write(WRITE_COMMANDS.SUBMIT_REPORT, parameters, {optimisticData, successData, failureData});

Git history confirms this area was recently fixed to avoid stale submit-manager routing, so this proposal should not change manager selection:

• PR [Payment due @Krishna2323] Fix submit report approver selection from stale policy data #88708 added getSubmitReportManagerAccountID() for stale policy data: [Payment due @Krishna2323] Fix submit report approver selection from stale policy data #88708
• PR [Payment due @Krishna2323] Fix submit approver selection after retract and workflow changes #89393 refined the same submit approver selection and workspace submit manager state: [Payment due @Krishna2323] Fix submit approver selection after retract and workflow changes #89393
• Commit 3bf9b884d5e60ce973b69582aacf9fac8100ad71 specifically changed isCurrentUserManager to use the computed managerID, not stale expenseReport.managerID.

The missing part is policy expense chat participant reconciliation. Existing policy expense chats are only reopened in createPolicyExpenseChats(); their participants are not recalculated from the new approver when another report is submitted:

App/src/libs/actions/Policy/Policy.ts

Lines 1594 to 1646 in 02a3327

	const oldChat = ReportUtils.getPolicyExpenseChat(cleanAccountID, policyID);
	// If the chat already exists, we don't want to create a new one - just make sure it's not archived
	if (oldChat) {
	workspaceMembersChats.reportCreationData[login] = {
	reportID: oldChat.reportID,
	};
	workspaceMembersChats.onyxOptimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${oldChat.reportID}`,
	value: {
	stateNum: CONST.REPORT.STATE_NUM.OPEN,
	statusNum: CONST.REPORT.STATUS_NUM.OPEN,
	},
	});
	workspaceMembersChats.onyxOptimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${oldChat.reportID}`,
	value: {
	private_isArchived: null,
	},
	});
	const currentTime = DateUtils.getDBTime();
	const reportActions = (reportActionsList ?? deprecatedAllReportActions)?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${oldChat.reportID}`] ?? {};
	for (const action of Object.values(reportActions)) {
	if (action.actionName !== CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW) {
	continue;
	}
	workspaceMembersChats.onyxOptimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${action.childReportID}`,
	value: {
	private_isArchived: null,
	},
	});
	workspaceMembersChats.onyxFailureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS}${action.childReportID}`,
	value: {
	private_isArchived: currentTime,
	},
	});
	}
	continue;
	}
	const optimisticReport = ReportUtils.buildOptimisticChatReport({
	participantList: [currentUserAccountID, cleanAccountID],
	chatType: CONST.REPORT.CHAT_TYPE.POLICY_EXPENSE_CHAT,
	policyID,
	ownerAccountID: cleanAccountID,
	notificationPreference,
	currentUserAccountID,
	});

Similar participant flows show why Approver 1 remains: Onyx deep-merges participants, so a user is removed only when the update explicitly sets that account key to null. removeFromRoom() does this in success data:

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

Lines 5119 to 5153 in 02a3327

	const removeParticipantsData: Record<number, null> = {};
	for (const accountID of targetAccountIDs) {
	removeParticipantsData[accountID] = null;
	}
	const pendingChatMembers = getPendingChatMembers(targetAccountIDs, reportMetadata?.pendingChatMembers ?? [], CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE);
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
	value: {
	pendingChatMembers,
	},
	},
	];
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
	value: {
	pendingChatMembers: reportMetadata?.pendingChatMembers ?? null,
	},
	},
	];
	// We need to add success data here since in high latency situations,
	// the OpenRoomMembersPage call has the chance of overwriting the optimistic data we set above.
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	participants: removeParticipantsData,
	},

Git history reinforces this: commit 7179e148b8ae5cc18d45707de2e004b067141ab2 fixed phantom participants because deep-merge rollback did not null added keys, and commit 67d705b09eb9433f10402aff1fe127b63aeb8b60 narrowed that rollback to avoid overwriting concurrent participant changes.

So the root cause is: SubmitReport updates the report manager, but the backend response/realtime update does not send an explicit participant diff for the submitter’s policy expense chat. Since Onyx merges participant objects, omitting old Approver 1 does not remove them.

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

Fix this in the SubmitReport backend response/realtime update, using the already-computed managerAccountID.

Small expected Onyx shape:

Report_{policyExpenseChatReportID}: {
  participants: {
+   [newApproverAccountID]: {},
+   [oldApproverAccountID]: null,
  },
}

The backend should:

• Find the submitter’s policy expense chat for report.policyID + report.ownerAccountID.
• Add managerAccountID to that chat’s participants.
• Remove only previous approvers that no longer have a current approver relationship to this submitter.
• Preserve access to already-submitted reports. Do not remove the old approver from the expense report participants/access list, only from the submitter’s policy expense chat.
• Return the same participant diff through realtime updates so other sessions converge.

Regression guard:

• Do not change getSubmitReportManagerAccountID() or the managerAccountID request payload. That protects fixes from [Payment due @Krishna2323] Fix submit report approver selection from stale policy data #88708/[Payment due @Krishna2323] Fix submit approver selection after retract and workflow changes #89393.
• Do not replace the whole participants object. Send only changed keys, matching the post-67d705b09 pattern, so concurrent notification preference/role changes are not overwritten.
• Only remove an old approver when the backend confirms they are not still the submitter’s approver through another active route, rule, or pending report relationship.

Suggested test coverage:

+ submit report 1 to Approver 1
+ assert submitter policy expense chat includes Approver 1
+ submit report 2 to Approver 2
+ assert submitter policy expense chat includes Approver 2
+ assert submitter policy expense chat does not include Approver 1
+ assert Approver 1 still has access to report 1

What alternative solutions did you explore? (Optional)

We could add an optimistic App-side participant update in submitReport(), but that would only affect the local client. The backend owns report access and chat membership, and all other clients still need the explicit participants: {[oldApproverID]: null} update.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).