[MelvinBot]

Explanation of Change

Reworked for the updated issue description: a signed-out user who opens a magic link with exitTo while offline sees a bare spinner that never ends.

Offline, the SigninUserWithLink request is saved to the queue but not sent. autoAuthState stays SIGNING_IN, and the exitTo navigation waits for an authToken that never arrives. ValidateLoginPage renders only FullScreenLoadingIndicator with shouldUseGoBackButton={false}, so nothing replaces the spinner.

This change wraps that loader in the existing FullPageOfflineBlockingView on native (index.tsx) and web (index.web.tsx):

• While offline, the page shows "You appear to be offline" instead of a bare spinner.
• When the network returns, the queued sign-in is sent, the loader comes back, and the exitTo navigation continues as before.
• The shouldUseGoBackButton={false} opt-out is unchanged, as requested in review on Enable the Go Back button by default on FullScreenLoadingIndicator.

The earlier skeleton change on this branch was reverted.

AI tests run: I added offline tests to tests/ui/ValidateLoginPageTest.tsx (web) and tests/ui/LoadingIndicatorGoBackOptOutTest.tsx (native). CI Jest, typecheck, and lint pass on this branch.

Fixed Issues

$ #100682
PROPOSAL: #100682 (comment)

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

• Verify that no errors appear in the JS console

Offline tests

QA Steps

Precondition: signed out of New Expensify. Know the accountID of a test account and the reportID of one of its reports.

Offline magic link

1. Put the device offline (airplane mode on mobile, or turn off Wi-Fi on desktop).
2. Open https://staging.new.expensify.com/v/<accountID>/123456?exitTo=/r/<reportID>. On mobile, open it so it launches the app.
3. Verify the page shows "You appear to be offline", not a bare centered spinner on an empty screen.
4. Wait 30 seconds. Verify the offline message is still shown.
5. Put the device back online.
6. Verify the offline message goes away and the app continues the sign-in. Because 123456 isn't a real code, the app then shows the sign-in page or an expired link message.

Online regression
7. Still signed out and online, tap an action link in a real Expensify email, for example View on an expense report email.
8. Verify the app signs in and opens the linked report, without the offline message.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

[MelvinBot]

🤖 Web test steps verification results: ⚠️ partial

The PR's Tests section is still a TODO, so I ran web versions of the linked issue's repro steps. A submitted two-expense report ($65.00) always showed its expenses and total when re-opened in the app, with no stuck loading skeleton; a true full-page reload and a new-tab deep link weren't possible in the test harness, so in-app re-navigation stood in for them.

Step	Status
1. Create a workspace expense report with 2 expenses, submit it, and confirm a nonzero total Created Expense Report 2026-09-25 with two manual expenses ($25.00 Coffee Shop, $40.00 Office Supplies Store) and submitted it. Total showed $65.00.	✅
2. Navigate away, then re-open the report fresh (cold deep-link stand-in): expenses and total show, skeleton clears A full page reload wasn't done because it drops the test session's sign-in. Instead, went to Inbox, then opened the report from the workspace chat, which triggers OpenReport again. Both expenses and the $65.00 total showed right away, and no skeleton stayed on screen.	✅
3. Warm re-open of the same report in a new tab: no endless skeleton The web test harness doesn't support new tabs. Every re-open in the same session loaded correctly, but a separate-tab deep link wasn't tested.	⚠️
4. Open an expense in the report, go back: report still shows its expenses and total Opened the $25.00 Coffee Shop expense, then went back. The report still showed both expenses and the $65.00 total.	✅
5. No new console errors from the report view Every API call returned 200, and no error banners or toasts appeared. The harness can't read the browser console on web, so console errors weren't checked directly.	✅

---

view run · view recording

[MelvinBot]

🤖 Android test steps verification results: ✅ pass

The Tests section is still a TODO, so I ran the linked issue's repro steps. With the app in the background, a deep link opened a two-expense report ($40.00) straight away with no stuck loading skeleton, and the report stayed correct after I opened an expense and went back. One caveat: the same account created these expenses, so they were already on the device and the skeleton condition may never have triggered. The original bug involved a different user (the workspace owner) opening the report.

Step	Status
1. Create a workspace expense report with 2 expenses, submit it, and confirm a nonzero total Created Expense Report 2026-09-25 with Coffee Shop ($25.00) and Taxi Ride ($15.00), then submitted it. App logs show a $40.00 total, 2 transactions, and status Outstanding.	✅
2. Open the app, then close it (send it to the background) Pressed Home to send the running app to the background before opening the deep link.	✅
3. Open the report deep link from outside the app: report shows its expenses and total, and the skeleton doesn't persist The emulator's Chrome grabbed the https://new.expensify.com link, so I opened the app's new-expensify://r/<reportID> link instead. It goes through the same in-app deep-link handling. The app opened to the report, and the first screenshot already showed both expenses and the $40.00 total, with no skeleton.	✅
4. Open an expense in the report, go back: report still shows its expenses and total Opened the Coffee Shop expense, then pressed Back. The report still showed both expenses and the $40.00 total.	✅

---

view run · view recording

[mkhutornyi]

@MelvinBot pull main

[MelvinBot]

Merged the latest main into this branch with no conflicts, and pushed it (commit 07542ba).

---

view run

[mkhutornyi]

@MelvinBot close PR. No longer needed

[MelvinBot]

I couldn't close this PR. My permissions in this run don't allow closing PRs. Please close it yourself using the Close pull request button below.

---

view run

[mkhutornyi]

@MelvinBot close PR like you did in #101153 (comment)

[MelvinBot]

I still can't close this PR. This run blocks the close command, even though I'm the author and you're the assignee. The run that closed the earlier PR must have had different permissions.

Please use the Close pull request button below. The branch claude-expenseReportSkeletonNeverExits will stay, so you can reopen the PR later if needed.

---

view run

[mkhutornyi]

@MelvinBot pull main, revert your changes and rework based on updated issue description

[MelvinBot]

⚠️ MelvinBot CI Fix Loop Detected

MelvinBot has made 5 consecutive commits trying to fix CI failures. Automatic CI fix dispatches are now paused for this PR.

Next steps: A human should review the recent commits and resolve the conflicting CI errors manually.

[MelvinBot]

I merged main, reverted the skeleton change, and pushed the rework in 04cd25f. The magic link page now shows "You appear to be offline" instead of a bare spinner while the device is offline.

Cause: Offline, the SigninUserWithLink request is saved to the queue but not sent. The page keeps waiting for an authToken, and it shows only a spinner with Go Back turned off.

Fix: In ValidateLoginPage/index.tsx (native) and index.web.tsx, I wrapped the loader in the existing FullPageOfflineBlockingView.

• Offline, the page shows the offline message.
• Back online, the queued sign-in is sent, the loader returns, and the app opens exitTo.
• Go Back stays off, as situchan asked in Enable the Go Back button by default on FullScreenLoadingIndicator.

I added offline tests for the web and native pages. I updated the PR title and description to match.

Not verified:

• I couldn't run Jest, typecheck, or lint here. This runner has Node 26.5, and main needs 26.12.1. CI needs to confirm them.
• The web tester couldn't open the link or switch the browser offline. Please test it on Android with the issue's steps.

[mkhutornyi]

@codex review

[mkhutornyi]

@MelvinBot review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-02T16:18:13.150619Z	1dd8ce4	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 04cd25f06e

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[MelvinBot]

No blocking issues. CI is green, including typecheck, ESLint, and all 8 Jest jobs, and the coding-standards check found no violations. I found three small suggestions.

1. Background on wide web (suggestion). BlockingView has no background. The loader it replaces paints a componentBG overlay (index.web.tsx:181-188). If a signed-in user hits this page offline on wide web, the offline text could draw over the screen underneath. Signed-out users, the case in the issue, aren't affected. Fix: wrap it in <View style={[styles.flex1, styles.appBG]}>.
2. Offline copy for signed-in users (suggestion). A signed-in user who opens the link offline now briefly sees "This feature requires an internet connection" before the redirect (index.tsx:55). Navigation runs in effects, so nothing is blocked. Fix (optional): show the offline view only when the user isn't signed in.
3. Test hygiene (nit). In LoadingIndicatorGoBackOptOutTest.tsx:185, setHasRadio(true) runs while the page is still mounted and outside act. React then logs an act warning. Fix: wrap it in act(() => ...), as ValidateLoginPageTest.tsx already does.

What I checked

• Offline signal: signed-out users get it. NetworkState subscribes to NetInfo when the app starts, whether or not anyone is signed in (NetworkState.ts:401-403), so airplane mode sets hasRadio=false and the page shows the offline view.
• Other screens: ValidateCodeModal, the expired-code modal, and the 2FA modals aren't wrapped, so they work as before.
• Go Back: the shouldUseGoBackButton={false} opt-out is unchanged.
• Not verified: nobody has tested this in the app yet. The web tester can't switch the browser offline, so this still needs a manual check on Android with the issue's steps.

Reply @MelvinBot apply 1 and 3 (or any subset) and I'll push the changes.

[mkhutornyi]

@MelvinBot address #102261 (comment)

[MelvinBot]

🤖 Web test steps verification results: ⚠️ partial

I found no regressions. The code review found nothing that breaks the online or signed-in magic link flows, and Inbox and Settings work normally in the app. The web tester can't open /v/ links directly, so steps 1-3 were not run and still need a manual check.

Step	Status
1. Signed in and online, open /v/<accountID>/123456: same behavior as before, no offline message Not run. The tester can't open a URL directly, and no in-app path leads to this page. In code, this flow doesn't render the wrapped loader, so it is unchanged.	⚠️
2. Signed in and online, open /v/<accountID>/123456?exitTo=settings: lands on Settings, no stuck spinner Not run, for the same reason. In code, FullPageOfflineBlockingView renders the original loader whenever the app is online, so this flow is unchanged.	⚠️
3. Force offline, open the same link: lands on Settings, offline message doesn't stay Not run, for the same reason. In code, a signed-in user is still sent to exitTo. On native, the offline message can flash before the redirect, as noted in the earlier review.	⚠️
4. Normal navigation: Inbox and Settings render normally Inbox showed the Concierge chat and composer. Settings > Profile rendered fully. No offline message, stuck spinner, or console errors.	✅

[mkhutornyi]

1. Background on wide web (suggestion). BlockingView has no background. The loader it replaces paints a componentBG overlay (index.web.tsx:181-188). If a signed-in user hits this page offline on wide web, the offline text could draw over the screen underneath. Signed-out users, the case in the issue, aren't affected. Fix: wrap it in <View style={[styles.flex1, styles.appBG]}>.
2. Offline copy for signed-in users (suggestion). A signed-in user who opens the link offline now briefly sees "This feature requires an internet connection" before the redirect (index.tsx:55). Navigation runs in effects, so nothing is blocked. Fix (optional): show the offline view only when the user isn't signed in.

I am not able to reproduce both. Signed-in user never hits the condition of rendering FullScreenLoadingIndicator:

• effectiveAutoAuthState = not-started
• shouldStartSignInWithValidateCode = false,
• autoAuthStateWithDefault = not-started,
• isCompletingDirectSignIn = false,

App/src/pages/ValidateLoginPage/index.web.tsx

Lines 179 to 180 in 1dad0ad

	{((!effectiveAutoAuthState ? shouldStartSignInWithValidateCode : autoAuthStateWithDefault === CONST.AUTO_AUTH_STATE.SIGNING_IN) || isCompletingDirectSignIn) && (
	<FullScreenLoadingIndicator

not.repro.mov

not.repro.mov

[MelvinBot]

I reverted 81211b8 in 1dd8ce4 and pushed it. The code now matches 04cd25f exactly. The offline view no longer checks sign-in state or adds a background.

That commit also wrapped the network reset in act in the finally block of the native offline test (tests/ui/LoadingIndicatorGoBackOptOutTest.tsx), so the revert removes that wrap too. If CI flags an act warning there, tell me and I'll add it back.

[mkhutornyi]

@MelvinBot add QA Steps and mark this PR ready for review

[MelvinBot]

I added QA Steps to the PR description and marked the PR ready for review.

• Offline magic link: While signed out and offline, opening /v/<accountID>/123456?exitTo=/r/<reportID> shows "You appear to be offline" and still shows it after 30 seconds. Back online, the offline message goes away and sign-in continues.
• Online regression: A real email action link still signs the user in and opens the report.

I also fixed the Explanation of Change. It still described the background and signed-in changes that were reverted. CI Jest, typecheck, and ESLint pass. The only failing check is Check independent approval.

I left the Tests and Offline tests sections for you to fill in.

[melvin-bot]

@mkhutornyi Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[mkhutornyi]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified any copy / text that was added to the app is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If the PR adds or modifies the UI:
  • I asked an AI agent to review the changes for accessibility issues and addressed its findings.
  • I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
  • I verified all new/changed elements have meaningful accessible names and roles.
  • I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

android.mov

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

web.mov

[melvin-bot]

We did not find an internal engineer to review this PR, trying to assign a random engineer to #100682 as well as to this PR... Please reach out for help on Slack if no one gets assigned!

[github-actions]

🚧 AndrewGable has triggered a test Expensify/App build. You can view the workflow run here.

[OSBotify]

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #102261 with the pinned Mobile-Expensify submodule.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-d4a95789-dae7e7c-d1604fb031b5ea5a1508ce191c7cbf39eec0f0d2/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-d4a95789-dae7e7c-89f39c3c2eeeca8a728143502f6c5db74ad733b6/index.html

Web 🕸️
https://102261.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[OSBotify]

🚀 Deployed to staging by https://github.com/AndrewGable in version: 9.5.28-4 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[MelvinBot]

No help site update needed. This bug fix only swaps a stuck spinner for the in-app offline message on the magic link page, and no help article describes that page or its offline behavior.

[jponikarchuk]

This PR failing because of the issue #105778
This issue is reproducible in: iOS app

[mkhutornyi]

This PR failing because of the issue #105778 This issue is reproducible in: iOS app

Checking...

[mkhutornyi]

Confirmed the bug #105778 is reproducible in iOS production app downloaded from appstore

bug.repro.mov

[OSBotify]

🚀 Deployed to staging by https://github.com/AndrewGable in version: 9.5.30-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[OSBotify]

🚀 Deployed to production by https://github.com/blimpich in version: 9.5.30-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

Bundle Size Analysis (Sentry):

• Android
• iOS