[Due for payment 2026-04-16] [ECUK] MFA executeScenario silently fails offline — no UI feedback, causes repeated taps

[MelvinBot]

[ECUK] MFA executeScenario silently fails when device is offline — no UI feedback, button stays enabled

When executeScenario is called while the device is offline (e.g., in the CHANGE-PIN scenario), Main.tsx silently exits early without any navigation or visual feedback. The calling screen appears completely frozen and the button stays fully enabled, so the user keeps tapping — causing a Sentry spike of 50x [MFA] Flow started logs in ~3 seconds.

Expected behavior

The user should see a proper offline indicator (similar to how BiometricsTestPage guards the call behind an isOffline check and renders FullPageOfflineBlockingView), and the button should be disabled or provide feedback when offline.

Current behavior

• Main.tsx silently exits early when offline — no navigation, no visual feedback
• The button on the calling screen (e.g., ChangePINPage) stays fully enabled
• The user keeps tapping, generating a flood of [MFA] Flow started logs

Root cause

The offline handling lives at the page level in BiometricsTestPage but is missing from the shared MFA context, leaving all other callers like ChangePINPage completely unprotected.

Platforms

Platform	Status
iOS	Affected
Android	Affected
Web	Affected

Slack thread: https://expensify.slack.com/archives/C09AP9F437A/p1775232248283069

[samranahm]

Proposal

What is the root cause of that problem?

The MFA flow has inconsistent offline handling. In Context/Main.tsx, the state machine exits early when offline, but executeScenario still logs flow start and dispatches INIT before that early exit. Also, ChangePINPage.tsx does not guard offline state or disable submit, while BiometricsTestPage.tsx does. This leaves some entry points unprotected, creating silent failure and repeated taps with log spam.

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

We should add a shared offline guard in MFA context and align caller UI behavior:

In Context/Main.tsx, short-circuit executeScenario before logging/tracking/dispatching when offline, so we do not emit repeated flow-start logs while offline.
In ChangePINPage.tsx, add offline UX parity with BiometricsTestPage.tsx:
render FullPageOfflineBlockingView when offline
disable the confirm button when offline
Keep BiometricsTest behavior as reference and reuse the same pattern for consistency.

    const executeScenario = useCallback(
        async <T extends MultifactorAuthenticationScenario>(scenario: T, params?: ExecuteScenarioParams<T>): Promise<void> => {
            if (isOffline) {
                addMFABreadcrumb('Flow blocked - offline', {
                    scenario,
                    platform,
                    hasPayload: params !== undefined && Object.keys(params).length > 0,
                });
                return;
            }

            startStateRef.current = await captureCredentialsState();

            const breadcrumbData = {
                scenario,
                hasPayload: params !== undefined && Object.keys(params).length > 0,
                platform,
                isOffline,
                hasAcceptedSoftPrompt: startStateRef.current.hasEverAcceptedSoftPrompt,
                serverHasAnyCredentials: startStateRef.current.hasServerCredentials,
            };

and in ChangePINPageContent

const {isOffline} = useNetwork();

<FullPageOfflineBlockingView>
    <Button
        success
        large
        text={...}
        onPress={handleSubmit}
        disabled={isOffline}
    />
</FullPageOfflineBlockingView>

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[chuckdries]

Hey @samranahm, thanks for the proposal but I'm going to keep this within the project. In the future, look for the Help Wanted label 👍

[samranahm]

Sure thing, thanks @chuckdries