[Due for payment 2026-06-01] [$250] Onboarding - Setup specialist has the onboarded user's email and a fallback avatar

[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: 9.3.74-1
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/13176677/test-cases/41237672
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.2
App Component: Other

Action Performed:

1. Navigate to staging.expensify.com (OD)
2. Select "Manage my company's expenses (10+)"
3. Sign up with a account with the following format: [anything]@tstsg.com
4. Click on "Get Started" and complete the signup process
5. When redirected to NewDot, select 51-100 - QBO - complete the onboarding
6. In the #admins room observe the setup specialist email and avatar

Expected Result:

Setup specialist is displayed as a qa.guide@team.expensify.com and has a non-fallback avatar

Actual Result:

Setup specialist is displayed as a just onboarded user's email with a fallback avatar

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/~022054952380608236287
• Upwork Job ID: 2054952380608236287
• Last Price Increase: 2026-05-14

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[MelvinBot]

Proposal

What is the root cause of that problem?

Race condition between an async Onyx.merge and a synchronous read of allPersonalDetails.

During onboarding, prepareOnboardingOnyxData resolves the setup specialist email via getPolicy(policyID)?.assignedGuide?.email, falling back to CONST.SETUP_SPECIALIST_LOGIN ('Setup Specialist'). When no personal detail exists for this login, the code writes an optimistic personal detail via Onyx.merge — but this is async.

Immediately after, buildOptimisticAddCommentReportAction reads from the module-level allPersonalDetails synchronously. Since Onyx.merge hasn't flushed yet, allPersonalDetails[assignedGuideAccountID] is undefined, so:

• displayName falls through to currentUserEmail → the onboarded user's email
• avatar falls through to undefined → fallback avatar

There's an existing comment acknowledging this area needs work: // This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850.

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

Instead of relying on Onyx.merge to propagate before the synchronous read, pass the guide's personal details directly to buildOptimisticAddCommentReportAction. Specifically:

1. Add optional actorDisplayName and actorAvatar parameters to buildOptimisticAddCommentReportAction.
2. In prepareOnboardingOnyxData, after resolving the guide's details, pass them explicitly when building the optimistic report actions (the assignedGuideEmail and default avatar are already computed locally).
3. In buildOptimisticAddCommentReportAction, prefer the explicitly passed values over the allPersonalDetails lookup.

This eliminates the race condition entirely — the correct display name and avatar are used without depending on async Onyx propagation.

What alternative solutions did you explore? (Optional)

• Awaiting Onyx.merge: Could await the merge before building report actions, but this would add latency to onboarding and complicate the synchronous flow.
• Using Onyx.multiSet: Batching the personal detail write with other onboarding data could help, but wouldn't guarantee the module-level variable is updated before the next synchronous read in the same call stack.

Supporting evidence

Fallback chain at ReportUtils.ts:6340:

text: allPersonalDetails?.[accountID]?.displayName ?? currentUserEmail ?? deprecatedCurrentUserEmail,

When allPersonalDetails[accountID] is undefined, this resolves to the current (onboarded) user's email.

Async merge at ReportUtils.ts:11703:

Onyx.merge(ONYXKEYS.PERSONAL_DETAILS_LIST, {
    [assignedGuideAccountID]: {
        accountID: assignedGuideAccountID,
        login: assignedGuideEmail,
        displayName: assignedGuideEmail,
        avatar: getDefaultAvatarURL({accountID: assignedGuideAccountID}),
    },
});

This write is async and won't update allPersonalDetails before the synchronous buildOptimisticAddCommentReportAction call that follows.

SETUP_SPECIALIST_LOGIN at CONST/index.ts:8771 is 'Setup Specialist' — a display string, not a real email — so getPersonalDetailByEmail will never find a match for it, always triggering the else branch with generateAccountID.

---

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.

[mukhrr]

Proposal

What is the root cause of that problem?

When a user finishes onboarding before the backend has assigned a real guide to their new policy, the optimistic data in getOnboardingMessages/prepareOnboardingOnyxData falls back to the literal string 'Setup Specialist' (the value of CONST.SETUP_SPECIALIST_LOGIN) — not a valid email — and uses that to build the actor for the welcome posts in the #admins room.

App/src/libs/ReportUtils.ts

Lines 11691 to 11712 in 1b89b63

	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.SETUP_SPECIALIST_LOGIN;
	const assignedGuidePersonalDetail = getPersonalDetailByEmail(assignedGuideEmail);
	let assignedGuideAccountID: number;
	let isOptimisticAssignedGuide = false;
	if (assignedGuidePersonalDetail?.accountID) {
	isOptimisticAssignedGuide = assignedGuidePersonalDetail.isOptimisticPersonalDetail ?? false;
	assignedGuideAccountID = assignedGuidePersonalDetail.accountID;
	} else {
	assignedGuideAccountID = generateAccountID(assignedGuideEmail);
	isOptimisticAssignedGuide = !assignedGuidePersonalDetail;
	// eslint-disable-next-line rulesdir/prefer-actions-set-data
	Onyx.merge(ONYXKEYS.PERSONAL_DETAILS_LIST, {
	[assignedGuideAccountID]: {
	accountID: assignedGuideAccountID,
	isOptimisticPersonalDetail: !assignedGuidePersonalDetail,
	login: assignedGuideEmail,
	displayName: assignedGuideEmail,
	avatar: getDefaultAvatarURL({accountID: assignedGuideAccountID}),
	},
	});
	}

Because 'Setup Specialist' isn't a real login, getPersonalDetailByEmail returns undefined, so we fall into the else branch and:

1. Generate a hash-based assignedGuideAccountID from the string 'Setup Specialist' via generateAccountID() — a random ID that doesn't correspond to any real Expensify account.
2. Write an optimistic personal detail with login: 'Setup Specialist', displayName: 'Setup Specialist', and avatar: getDefaultAvatarURL({accountID: <hash>}) (a fallback avatar).

That synthetic account is then used as the actorAccountID for the optimistic onboarding messages. Since the hash-derived accountID doesn't match any real personal detail returned from the backend later, the report-action header ends up resolving the actor by falling back to the only login it has on hand — the just-onboarded user's — and the fallback avatar sticks. The TODO comment immediately above the line confirms the fallback is wrong and links to Expensify/Expensify#507850.

The expected fallback is qa.guide@team.expensify.com, which has a known stable accountID (CONST.ACCOUNT_ID.QA_GUIDE = 14365522, defined at

App/src/CONST/index.ts

Line 3189 in 1b89b63

QA_GUIDE: Number(Config?.EXPENSIFY_ACCOUNT_ID_QA_GUIDE ?? 14365522),

) and whose personal details (including the real avatar) the backend already serves.

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

Fall back to the real QA Guide email + accountID instead of the placeholder string, so the optimistic actor resolves to a real Expensify account with a real avatar:

-    // This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
-    const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.SETUP_SPECIALIST_LOGIN;
+    const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.EMAIL.QA_GUIDE;
     const assignedGuidePersonalDetail = getPersonalDetailByEmail(assignedGuideEmail);

And in the optimistic-personal-detail branch, use the known QA Guide accountID when the fallback path is taken instead of a random hash, so we don't fabricate an account that the backend will never reconcile:

-        assignedGuideAccountID = generateAccountID(assignedGuideEmail);
+        assignedGuideAccountID = assignedGuideEmail === CONST.EMAIL.QA_GUIDE ? CONST.ACCOUNT_ID.QA_GUIDE : generateAccountID(assignedGuideEmail);

With these two changes the optimistic merge into PERSONAL_DETAILS_LIST writes login: 'qa.guide@team.expensify.com' at the canonical QA_GUIDE accountID; when the backend later sends the real personal-details row for that accountID (with the proper avatar) it cleanly overwrites the optimistic stub — no orphan hash account, no fallback avatar, no leak of the current user's email into the actor slot.

The same CONST.SETUP_SPECIALIST_LOGIN filter in OptionsListUtils and PersonalDetailOptionsListUtils can stay as-is — it's only used to hide that specific placeholder from option lists, and after this fix we simply stop creating that placeholder in the first place.

What alternative solutions did you explore?

• Leave the fallback string but special-case 'Setup Specialist' in the avatar/name resolution layer. Rejected — it pushes onboarding-specific knowledge into generic report-action rendering and leaves the optimistic accountID disconnected from the eventual backend record, which is the deeper cause of the "current user's email shows up" symptom.
• Block the optimistic posts entirely until assignedGuide is populated on the policy. Rejected — onboarding messages need to appear immediately for offline-first UX; deferring them would regress the #admins welcome flow for everyone, not just the no-guide-yet case.

[melvin-bot]

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

[melvin-bot]

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

[dilshodmackbook-sketch]

Proposal

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

After completing the "Manage my company's expenses (10+)" onboarding, the setup-specialist welcome message in the #admins room is rendered with the just-onboarded user's own email as the author and a fallback avatar, instead of qa.guide@team.expensify.com with the real setup-specialist avatar.

What is the root cause of that problem?

When the policy's assignedGuide hasn't been populated yet at optimistic-data construction time, prepareOnboardingOnyxData falls back to CONST.SETUP_SPECIALIST_LOGIN, which is the literal display string 'Setup Specialist' — not an email and not a real account:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L11690-L11712

const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.SETUP_SPECIALIST_LOGIN;
const assignedGuidePersonalDetail = getPersonalDetailByEmail(assignedGuideEmail);
...
} else {
    assignedGuideAccountID = generateAccountID(assignedGuideEmail);
    ...
    Onyx.merge(ONYXKEYS.PERSONAL_DETAILS_LIST, {
        [assignedGuideAccountID]: { ..., login: assignedGuideEmail, displayName: assignedGuideEmail, avatar: getDefaultAvatarURL({accountID: assignedGuideAccountID}) },
    });
}
const actorAccountID = shouldPostTasksInAdminsRoom ? assignedGuideAccountID : CONST.ACCOUNT_ID.CONCIERGE;

Because 'Setup Specialist' can't be resolved by getPersonalDetailByEmail, the else branch runs and assignedGuideAccountID becomes generateAccountID('Setup Specialist') — a fabricated account ID that no backend record will ever match. The optimistic personal detail written for it carries displayName: 'Setup Specialist' and a default avatar URL.

That fabricated actorAccountID is then used to build the welcome-message report action via buildOptimisticAddCommentReportAction, where person[0].text and avatar are looked up from allPersonalDetails[accountID]:

https://github.com/Expensify/App/blob/main/src/libs/ReportUtils.ts#L6336-L6345

Two things compound here:

1. The lookup misses synchronously — the Onyx.merge on L11702 is async and the module-level allPersonalDetails cache isn't warm yet when the builder runs on L11736 — so person[0].text falls through to currentUserEmail (the onboarded user's email) and avatar is undefined (fallback avatar).
2. Even after the merge settles, the fabricated account never reconciles with the backend, so the correct identity (qa.guide@team.expensify.com + real avatar) never arrives for that ID.

The Concierge branch right below shows the correct pattern — it uses the known numeric CONST.ACCOUNT_ID.CONCIERGE, never generateAccountID.

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

Fall back to the real QA Guide identity instead of the placeholder string, so the optimistic actor is a real Expensify account that the backend already serves personal details (and a real avatar) for. Both constants already exist — CONST.EMAIL.QA_GUIDE (src/CONST/index.ts#L194) and CONST.ACCOUNT_ID.QA_GUIDE = 14365522 (src/CONST/index.ts#L3187).

-    // This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
-    const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.SETUP_SPECIALIST_LOGIN;
+    const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.EMAIL.QA_GUIDE;
     const assignedGuidePersonalDetail = getPersonalDetailByEmail(assignedGuideEmail);

     } else {
-        assignedGuideAccountID = generateAccountID(assignedGuideEmail);
+        assignedGuideAccountID = assignedGuideEmail === CONST.EMAIL.QA_GUIDE ? CONST.ACCOUNT_ID.QA_GUIDE : generateAccountID(assignedGuideEmail);
         isOptimisticAssignedGuide = !assignedGuidePersonalDetail;

With a real account ID as actorAccountID, the welcome message's actorAccountID matches a record the backend already provides, so the header resolves to qa.guide@team.expensify.com with the real avatar. This also dissolves the synchronous-read race: when the QA Guide's personal details are already cached, the if branch is taken and no optimistic write/race happens at all; when they aren't, the correct details still arrive against a real account ID instead of a dead fabricated one.

Note: the isOptimisticAssignedGuide cleanup block (ReportUtils.ts#L12367) should still only null out the entry when we actually wrote an optimistic one — guard it so we never wipe real cached QA Guide details.

What alternative solutions did you explore? (Optional)

• Only fixing the race — pass the guide's display name/avatar explicitly into buildOptimisticAddCommentReportAction instead of relying on the warm cache. This removes the fallback-to-current-user symptom, but with CONST.SETUP_SPECIALIST_LOGIN still in play you'd optimistically show 'Setup Specialist' with a default avatar — which still doesn't match the expected qa.guide@team.expensify.com + real avatar, and the fabricated account still never reconciles.
• Awaiting Onyx.merge before building the actions — adds latency to onboarding and still doesn't fix the fabricated-account-ID problem.

[github-actions]

⚠️ @mukhrr 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).

[github-actions]

⚠️ @dilshodmackbook-sketch 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).

[wildan-m]

Proposal

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

After completing the new-workspace onboarding flow (sign up → "Manage my company's expenses (10+)" → company size 51-100 → QBO → finish), the setup-specialist welcome message that appears in the #admins room is rendered with the just-onboarded user's own email as the author and with a fallback (default) avatar, instead of qa.guide@team.expensify.com with the real setup-specialist avatar.

What is the root cause of that problem?

The optimistic setup-specialist personal detail is created with Onyx.merge, but the very next synchronous call to buildOptimisticAddCommentReportAction reads from the module-level allPersonalDetails cache, which is only refreshed asynchronously by an Onyx.connect callback. So at the moment the welcome message action is built, the cache does not yet contain the entry we just merged for the setup specialist.

In prepareOnboardingOnyxData, the assigned-guide branch creates the optimistic personal detail here:

App/src/libs/ReportUtils.ts

Lines 11692 to 11712 in 7152d98

	const assignedGuideEmail = getPolicy(targetChatPolicyID)?.assignedGuide?.email ?? CONST.SETUP_SPECIALIST_LOGIN;
	const assignedGuidePersonalDetail = getPersonalDetailByEmail(assignedGuideEmail);
	let assignedGuideAccountID: number;
	let isOptimisticAssignedGuide = false;
	if (assignedGuidePersonalDetail?.accountID) {
	isOptimisticAssignedGuide = assignedGuidePersonalDetail.isOptimisticPersonalDetail ?? false;
	assignedGuideAccountID = assignedGuidePersonalDetail.accountID;
	} else {
	assignedGuideAccountID = generateAccountID(assignedGuideEmail);
	isOptimisticAssignedGuide = !assignedGuidePersonalDetail;
	// eslint-disable-next-line rulesdir/prefer-actions-set-data
	Onyx.merge(ONYXKEYS.PERSONAL_DETAILS_LIST, {
	[assignedGuideAccountID]: {
	accountID: assignedGuideAccountID,
	isOptimisticPersonalDetail: !assignedGuidePersonalDetail,
	login: assignedGuideEmail,
	displayName: assignedGuideEmail,
	avatar: getDefaultAvatarURL({accountID: assignedGuideAccountID}),
	},
	});
	}

Then immediately calls buildOptimisticAddCommentReportAction with the new actorAccountID:

App/src/libs/ReportUtils.ts

Lines 11737 to 11738 in 7152d98

	const textComment = buildOptimisticAddCommentReportAction({text: message, actorAccountID, createdOffset: 1, delegateAccountIDParam: undefined});
	const textCommentAction: OptimisticAddCommentReportAction = textComment.reportAction;

Inside that builder, both the displayed author name (person[0].text) and the avatar are looked up from allPersonalDetails[actorAccountID]:

App/src/libs/ReportUtils.ts

Lines 6325 to 6346 in 7152d98

	const accountID = actorAccountID ?? currentUserAccountID ?? deprecatedCurrentUserAccountID ?? CONST.DEFAULT_NUMBER_ID;
	// Falls back to module-level delegateEmail (from Onyx.connect) for callers not yet migrated; will be removed in https://github.com/Expensify/App/issues/66425
	const effectiveDelegateAccountID = delegateAccountIDParam ?? (delegateEmail ? getPersonalDetailByEmail(delegateEmail)?.accountID : undefined);
	// Remove HTML from text when applying optimistic offline comment
	return {
	commentText,
	reportAction: {
	reportActionID,
	reportID,
	actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
	actorAccountID: accountID,
	person: [
	{
	style: 'strong',
	text: allPersonalDetails?.[accountID]?.displayName ?? currentUserEmail ?? deprecatedCurrentUserEmail,
	type: 'TEXT',
	},
	],
	automatic: false,
	avatar: allPersonalDetails?.[accountID]?.avatar,
	created: getDBTimeWithSkew(Date.now() + createdOffset),

The allPersonalDetails cache is populated only via the Onyx subscription callback:

App/src/libs/ReportUtils.ts

Lines 1059 to 1071 in 7152d98

	let allPersonalDetails: OnyxEntry<PersonalDetailsList>;
	let allPersonalDetailLogins: string[];
	let currentUserPersonalDetails: OnyxEntry<PersonalDetails>;
	Onyx.connect({
	key: ONYXKEYS.PERSONAL_DETAILS_LIST,
	callback: (value) => {
	if (deprecatedCurrentUserAccountID) {
	currentUserPersonalDetails = value?.[deprecatedCurrentUserAccountID] ?? undefined;
	}
	allPersonalDetails = value ?? {};
	allPersonalDetailLogins = Object.values(allPersonalDetails).map((personalDetail) => personalDetail?.login ?? '');
	},
	});

Because Onyx.merge is asynchronous, that callback has not fired yet by the time the builder runs. The lookup therefore returns undefined for both fields. The displayName then falls back to currentUserEmail ?? deprecatedCurrentUserEmail (the onboarded user's own email), and the avatar stays undefined so the UI renders the generic fallback avatar.

This is purely a frontend optimistic-data race; the backend response later sets the correct values, but the optimistic action that the user sees during/after onboarding is built with stale cache state.

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

Stop relying on the not-yet-warm Onyx cache for the setup-specialist's display fields in this optimistic-action path. We already know the values we just merged into Onyx (assignedGuideEmail, the optimistic accountID, and the default avatar URL), so we should use them directly when building the welcome message action.

The smallest contained fix is in prepareOnboardingOnyxData, immediately after buildOptimisticAddCommentReportAction returns: overwrite the action's person[0].text and avatar with the locally known values for the assigned guide.

Concretely, for the welcome textCommentAction (and for the bespoke Concierge action when it's built via the same path, if applicable), set:

• person to a single TEXT entry whose text is the resolved assigned-guide displayName — preferring assignedGuidePersonalDetail?.displayName ?? assignedGuidePersonalDetail?.login when an existing personal detail was found, otherwise the literal assignedGuideEmail we used for the optimistic merge (so when the fallback CONST.SETUP_SPECIALIST_LOGIN is in effect, that label is displayed instead of the current user's email).
• avatar to assignedGuidePersonalDetail?.avatar ?? getDefaultAvatarURL({accountID: assignedGuideAccountID}) — matching exactly what was merged into PERSONAL_DETAILS_LIST a few lines above, so the chat row gets a deterministic default avatar tied to the setup-specialist accountID, not a generic anonymous fallback.

This keeps the optimistic action self-consistent with the optimistic personal detail we wrote to Onyx in the same function, removes the dependency on the async allPersonalDetails callback ordering, and does not change the shape of buildOptimisticAddCommentReportAction or any of its other callers.

After the backend response replaces the optimistic action with the real one, the display continues to behave as it does today.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90693-onboarding-guide-display?expand=1

What alternative solutions did you explore? (Optional)

Extending buildOptimisticAddCommentReportAction with explicit optional actorDisplayName and actorAvatar parameters and passing them from prepareOnboardingOnyxData. This is cleaner in principle but expands a widely-used builder's API and forces every other call site to reason about the new params; the contained post-construction override above gets the same correctness with a much smaller blast radius.