[Exploratory] LHN-Trial badge banner in concierge but admin chat shows trial badge in LHN.

[applause-bot]

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

---

Version Number: V9.5.75
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #100278
Email or phone of affected tester (no customers): Vjgh@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Left Hand Navigation (LHN)

Action Performed:

1. Launch app without plus gmail account
2. Onboarding via something else
3. Toggle on forced offline
4. Create workspace with ALL currency
5. Go lhn and note concierge above trial badge shown
6. Toggle off forced offline
7. Note trial badge moved above admin chat
8. Open admin room and note no trial badge in header
9. Open concierge chat and note trial badge in header

Expected Result:

Trial badge banner in concierge so concierge chat must show trial badge in LHN

Actual Result:

Trial badge banner in concierge but admin chat shows trial badge in LHN.

In offline, it shows correctly in Concierge but in online badge moves to admin.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

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

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

[hungvu193]

@MelvinBot Find the offending PR

[MelvinBot]

Offending PR: #55589 ("Display get started tooltip for only onboarding admin room", nkdengineer, merged 2025-01-31).

That PR changed the LHN free‑trial badge to read the server NVP nvp_introSelected.choice instead of the local Onyx key onboardingPurposeSelected, and deleted the comment that warned this exact thing would break: // During the onboarding flow, the introSelected NVP is not yet available.

Proposal

What is the root cause of that problem?

isChatUsedForOnboarding() decides between the #admins room and Concierge based on the onboarding purpose you hand it (src/libs/ReportUtils.ts:13367-13369).

The two places that render the trial badge feed it different sources for that same argument:

Call site	Purpose source	Availability
LHN badge — LHNTooltipContextProvider.tsx:39 → OnboardingBadge.tsx:25	nvp_introSelected.choice	server NVP — only after you're back online
Chat header — HeaderView.tsx:326-327	onboardingPurposeSelected	local key, set client-side during onboarding

That mismatch is the whole bug, and it explains the offline → online flip exactly: while offline the LHN has no synced NVP so it falls through to Concierge; the moment the NVP lands it re-evaluates and moves the badge to #admins, while the header keeps using the local key and stays on Concierge.

How it got this way

• Move free trial banner to #admins room for users selecting MANAGE_TEAM onboarding intent #53895 first routed the badge to #admins for the MANAGE_TEAM intent. It correctly used onboardingPurposeSelected, with the comment "During the onboarding flow, the introSelected NVP is not yet available."
• Display get started tooltip for only onboarding admin room #55589 then swapped the badge call to introSelected?.choice (commit ab6c1cd) and a follow-up "fix lint" commit in the same PR dropped the now-unused subscription and that warning comment.
• The header was never migrated, so the two have disagreed ever since. Later refactors (fix: free trial left banner show on admin room and concierge chat #69620, the OptionRow extraction, the LHN tooltip context provider) only moved the code around — they didn't change the source.

onboardingPurposeSelected is purely local: it's written in Welcome/index.ts:52 and OnboardingFlow.ts:131 and cleared on sign-out, which is why it survives forced-offline while the NVP does not.

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

Make both call sites use the same purpose value. The header's source is the correct one because it's available immediately and offline, so have LHNTooltipContextProvider fall back to it:

• Subscribe to ONYXKEYS.ONBOARDING_PURPOSE_SELECTED in LHNTooltipContextProvider.tsx and set onboardingPurpose to introSelected?.choice ?? onboardingPurposeSelected, restoring the deleted comment explaining why the local key is needed.

Longer term, isChatUsedForOnboarding should resolve the purpose itself rather than trusting each caller to pass the right one — that's what let these two drift apart silently.

What alternative solutions did you explore? (Optional)

Changing the header to use introSelected?.choice would also make them agree, but it's the wrong direction: it would make the header wrong offline and during onboarding instead of fixing anything.

Confidence and what I did not verify

Medium. The divergent-source defect is confirmed by code — that argument is the only input that differs between the two call sites, so it is the only thing that can make them disagree the way the report describes. I did not reproduce the flow on a device, so I have not observed the concrete values (introSelected.choice vs onboardingPurposeSelected) at the moment the badge jumps. Worth confirming with a fresh non-plus account before implementing.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/100834) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.