Public room - Public room loads infinitely after dismissing AI modal

[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: 9.4.50-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/test-runs/67668897/folder/13176964/41237763/1630482459?q=public+room&issue_type=jira&sort=-identifier
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Mac 26.5 / Chrome
App Component: Chat Report View

Action Performed:

1. Go to staging.new.expensify.com
2. Log out if logged in.
3. Go to public room - https://staging.new.expensify.com/r/1540486774487195
4. Wait for AI modal to appear.
5. Dismiss AI modal.

Expected Result:

Public room will not load infinitely after dismissing AI modal.

Actual Result:

Public room loads infinitely after dismissing AI modal.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7225988_1785882707441.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7225988

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022084828669403690919
• Upwork Job ID: 2084828669403690919
• Last Price Increase: 2026-08-05

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

[MelvinBot]

Proposal

What is the root cause of that problem?

The AI Features promo modal (the "AI modal" in the repro) is being shown to logged-out / anonymous users, when it should only ever appear for signed-in users. It's a promo for authenticated AI features and has no business appearing on a public room for an anonymous visitor.

The eligibility check in useAIFeaturesPromoModal.ts:73-82 gates on !!session?.authToken — but anonymous users also carry an authToken (only authTokenType differs, ANONYMOUS), so the gate passes for them. There is no isAnonymousUser() guard, and useShouldSuppressPromotionalUI.ts:15-24 only suppresses supportal/copilot sessions — not anonymous ones.

Dismissing the modal (AIFeaturesPromoModal.tsx:73-80) then fires a persisted DISMISS_PRODUCT_TRAINING write, which an anonymous session isn't authorized to make — the resulting reauth pauses the network queue and starves the OPEN_REPORT the public room is waiting on, so the loading skeleton never resolves → infinite load.

Evidence & data flow

• The modal + its trigger hook are mounted for anonymous public-room sessions (they run inside AuthScreens with an anon token).
• Why it shows: isEligible requires !!session?.authToken — true for anonymous (isAnonymousUser checks authTokenType === ANONYMOUS, src/libs/actions/Session/index.ts). No anonymous exclusion anywhere in the gate or in useShouldSuppressPromotionalUI.
• Why it hangs after dismiss (medium confidence): both exit paths do Navigation.goBack() + dismissProductTraining() → API.write(DISMISS_PRODUCT_TRAINING) (Welcome/index.ts). On an anonymous session this write is unauthorized → Reauthentication.ts pauses the SequentialQueue; anonymous reauth has no real credentials, so it stalls/loops. That starves OPEN_REPORT (Report/index.ts), whose optimistic isLoadingInitialReportActions:true never flips back, so ReportActions.tsx:71-95 keeps rendering the skeleton.

The "why the modal shows to anonymous users" part is high confidence (verified in code). The exact downstream queue-stall mechanism is medium confidence — it depends on how the backend handles a DISMISS_PRODUCT_TRAINING write from an anonymous session, which lives outside the App repo. Regardless of the precise stall path, the modal should not appear for anonymous users in the first place, which removes the trigger entirely.

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

Add an anonymous-user guard to the promo modal's eligibility so it never shows to logged-out users. The cleanest spot is the isEligible check in useAIFeaturesPromoModal.ts: require the session to be non-anonymous (e.g. session?.authTokenType !== CONST.AUTH_TOKEN_TYPES.ANONYMOUS) in addition to !!session?.authToken. Alternatively (or additionally), extend useShouldSuppressPromotionalUI to also suppress anonymous sessions, which would cover all promo/training/onboarding UI in one place.

What alternative solutions did you explore? (Optional)

Blocking the DISMISS_PRODUCT_TRAINING write for anonymous sessions would stop the queue stall, but it treats the symptom — the modal still wrongly appears. Fixing eligibility is the correct root-cause fix.

---

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

[melvin-bot]

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

[melvin-bot]

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

[j3ffffff]

Proposal

What is the root cause of that problem?

useAIFeaturesPromoModal (src/hooks/useAIFeaturesPromoModal.ts, lines 73–82) determines eligibility by checking !!session?.authToken, among other conditions — but never checks isAnonymousUser. Anonymous users who visit a public room receive a temporary anonymous auth token (session.authToken is truthy), so all the eligibility conditions pass and the AI Features Promo Modal is shown to them.

When the anonymous user dismisses the modal, two things happen in closeModal() / confirmAndCloseModal():

1. Navigation.goBack() — navigates back, which on web causes the route to change and ReportFetchHandler to re-trigger fetchReport(), re-queueing an OPEN_REPORT network request.
2. dismissProductTraining(...) — calls API.write(WRITE_COMMANDS.DISMISS_PRODUCT_TRAINING, ...), which queues a write request before the OPEN_REPORT in the SequentialQueue.

For an anonymous session, DISMISS_PRODUCT_TRAINING cannot be persisted to a real account (no real NVP can be written). If this request retries or stalls, it blocks the queue so the OPEN_REPORT that follows it never processes. Since openReport's optimistic data already set isLoadingInitialReportActions: true, and neither the success nor failure handler ever fires, the loading skeleton on the public room stays visible indefinitely.

Key files:

• src/hooks/useAIFeaturesPromoModal.ts — missing isAnonymousUser guard (lines 73–82)
• src/components/AIFeaturesPromoModal.tsx — closeModal / confirmAndCloseModal (lines 73–81)
• src/hooks/useInFlightRequests.ts — useIsReportLoadPending latch persists until isLoadingInitialReportActions clears (lines 175–196)

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

In useAIFeaturesPromoModal (src/hooks/useAIFeaturesPromoModal.ts), add a call to useIsAnonymousUser() and include !isAnonymousUser in the isEligible condition. This prevents the modal from ever appearing for anonymous users visiting a public room, removing the entire failure path:

const isEligible =
    isAllOnyxLoaded &&
    !!session?.authToken &&
    !isAnonymousUser &&   // ← add this guard
    !isLoadingApp &&
    ...

No other changes are needed — once the modal is suppressed for anonymous users, neither the queue-blocking write nor the stuck loading state can occur.

What alternative solutions did you explore? (Optional)

An alternative would be to guard the dismissProductTraining call inside AIFeaturesPromoModal so it is skipped for anonymous users, or to make the SequentialQueue more resilient to write failures. But both are more invasive and treat the symptom rather than the cause. The cleanest fix is preventing the modal from appearing for anonymous users entirely, since they have no persistent account to save a dismissal against.

[oqildev]

@marcaaron Can you pls assign me per #82013 (comment) ?! thanks

[nkdengineer]

The issue can still be reproduced even though we don't show the AI feature for anonymous user