[$175] Onboarding modal reappears and unexpected error is displayed when login offline

[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.94-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/75702442/41236545/1798267583?sort=%2Bstatus_id
Email or phone of affected tester (no customers): gocematetestteest@testt.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: windows 10/chrome
App Component: Other

Action Performed:

1. Create a new user (Without +)
2. When onboarding modal is displayed go offline
3. Select "Track expenses for my business"

Expected Result:

Onboarding process should continue with no errors

Actual Result:

Onboarding modal keep reappearing when user hit Ctrl+D and Unexpected errors are displayed on Concierge page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7269574_1790358717059.Recording__1735.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7269574

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022103564087722443885
• Upwork Job ID: 2103564087722443885
• Last Price Increase: 2026-09-25

Issue Owner

Current Issue Owner: @iwiznia

[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/40c3611df967e577b6c30e970e8ecec771a8f9f8bbbf6c8bd8ab3420e4ef8d95

[MelvinBot]

Proposal

What is the root cause of that problem?

On web, the "Track expenses for my business" flow sends CompleteGuidedSetup with API.makeRequestWithSideEffects instead of API.write (src/libs/actions/Report/index.ts:6162-6174). Side-effect requests skip the offline queue and never retry.

When the user is offline:

1. The optimistic data marks onboarding complete and adds the Concierge welcome messages.
2. The request fails right away. The middleware resolves it as a failure (Reauthentication.ts:213-216), so failureData runs.
3. failureData adds "Unexpected error posting the comment" to each Concierge message and sets hasCompletedGuidedSetupFlow back to false.
4. Ctrl+D opens the Test Tools modal through a navigation. OnboardingGuard sends every navigation back to onboarding while onboarding is incomplete (OnboardingGuard.ts:240-286).
5. The request is never replayed, so nothing clears the errors after you reconnect.

This path most likely started with Add trackExpensesWithConcierge onboarding RHP variant. It affects any caller that passes shouldWaitForRHPVariantInitialization: true, including "Manage team" on web.

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

In completeOnboarding, take the side-effect branch only when the user is online. Offline, fall through to the existing API.write path. The request then joins the queue after CreateWorkspace, keeps its optimistic data, and replays when the user reconnects. Use isOfflineNetwork(), which is already imported in that file.

The callers already handle a missing response. useAutoCreateTrackWorkspace.ts falls back to the trackExpensesWithConcierge variant.

Add a unit test. When the user is offline and shouldWaitForRHPVariantInitialization is true, the test should expect a queued CompleteGuidedSetup write and hasCompletedGuidedSetupFlow still true.

What alternative solutions did you explore? (Optional)

Disable "Continue" on the onboarding steps while offline. This avoids the errors but does not meet the expected result, which is that onboarding continues offline.

Investigation details

• Choice mapping: "Track expenses for my business" is TRACK_BUSINESS (newDotTrackWorkspace). Its flow is Purpose → Name → auto-created workspace → completeOnboarding. The name step is enabledWhenOffline, with no offline guard.
• waitForWrites returns right away when offline, so the side-effect request fires immediately.
• The Submit and "Looking around" flows call completeOnboarding without shouldWaitForRHPVariantInitialization. They use API.write and work offline.
• Test Tools "Force offline" does not block the fetch. The request can reach the server before the queued CreateWorkspace, with a policy ID that does not exist yet. The client has already applied failureData in either case. The backend's response to this ordering is internal and not verified here.
• Web test: the automated tester could not go offline before choosing a purpose. The onboarding modal blocks access to "Force offline". With the steps done online, no errors appeared, which fits this analysis. The failure depends on being offline when CompleteGuidedSetup is sent.

---

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

---

view run · view recording

[melvin-bot]

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

[melvin-bot]

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

[ashusatyarthi-wq]

Proposal

What is the root cause of that problem?

In src/libs/actions/Report/index.ts within completeOnboarding (lines 6162-6174), when selecting "Track expenses for my business", shouldWaitForRHPVariantInitialization evaluates to true.

Under this path, the function dispatches the API call using:

await waitForWrites(SIDE_EFFECT_REQUEST_COMMANDS.COMPLETE_GUIDED_SETUP);
...
return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.COMPLETE_GUIDED_SETUP, parameters, {optimisticData, successData, failureData});

Key Architectural Conflict:

1. API.makeRequestWithSideEffects is designed exclusively for online requests where the client requires an immediate response from the server before continuing (specifically to extract nvp_onboardingRHPVariant).
2. Unlike API.write (which queues writes into SequentialQueue to run upon reconnection and applies optimistic Onyx updates immediately), API.makeRequestWithSideEffects rejects and fails immediately when the device is offline (isOfflineNetwork()).
3. Because the request fails immediately offline, failureData is triggered or the optimistic Onyx state is reverted, leaving the onboarding state un-cleared. Consequently, the user is navigated to Concierge with unexpected error banners, and the onboarding modal reappears upon pressing Ctrl+D / refreshing.

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

In src/libs/actions/Report/index.ts, check network connectivity using the already imported isOfflineNetwork() before deciding whether to wait on side-effect responses:

if (shouldWaitForRHPVariantInitialization) {
    await waitForWrites(SIDE_EFFECT_REQUEST_COMMANDS.COMPLETE_GUIDED_SETUP);
    resetOnboardingStackToRoot();

    if (isOfflineNetwork()) {
        // eslint-disable-next-line rulesdir/no-multiple-api-calls
        return API.write(WRITE_COMMANDS.COMPLETE_GUIDED_SETUP, parameters, {optimisticData, successData, failureData});
    }

    // eslint-disable-next-line rulesdir/no-api-side-effects-method
    return API.makeRequestWithSideEffects(SIDE_EFFECT_REQUEST_COMMANDS.COMPLETE_GUIDED_SETUP, parameters, {optimisticData, successData, failureData});
}

Why this is completely safe:

• When offline: No server response can be retrieved anyway. Routing through API.write ensures the request is safely queued into SequentialQueue to be executed on the backend when connection is restored, while applying optimisticData immediately so the user can continue past onboarding with zero errors.
• When online: The existing API.makeRequestWithSideEffects execution continues identically, preserving live nvp_onboardingRHPVariant resolution.

What alternative solutions did you explore? (Optional)

We could modify API.makeRequestWithSideEffects globally to support offline fallback, but handling it directly in completeOnboarding isolates the fix to onboarding without risking unintended side effects across other API commands.

Test Plan:

1. Create a fresh test user account (without +).
2. When the onboarding modal appears, disconnect internet connection (go offline).
3. Select "Track expenses for my business".
4. Verify onboarding modal closes cleanly with no unexpected errors on the Concierge page.
5. Hit Ctrl+D / reload -> Verify onboarding modal does not reappear.
6. Reconnect internet -> Verify backend setup syncs cleanly via SequentialQueue.

[melvin-bot]

📣 @ashusatyarthi-wq! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[ashusatyarthi-wq]

Contributor details
Your Expensify account email: ashusatyarthi@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010e53044b5828fe60

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!