Report Field - Refresh shows Initial Value page instead of Add Field page

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.4.17-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94014
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, iPhone 13 / iOS 26.5, Samsung Galaxy A52 / Android 14
App Component: Workspace Settings

Action Performed:

Preconditions:

1. logged in to any user that has at least one workspace
2. Go to workspace setting -> Report

Steps:

1. Tap Add field -> enter a name -> select type List ->add at least two list values
2. Click back button -> tap Initial value -> select a value
3. Click back button -> tap list value -> toggle off a list value that was selected as initial value
4. Click back button -> tap initial value
5. Refresh while on the Initial value page

Expected Result:

User return to the Add field page

Actual Result:

User remains in initial value page after refresh

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188155_1782178359218.initial_value_refresh.mp4

View all open jobs on GitHub

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

[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/27505498fd17cfef95e850ff2ff8e15fc796f673155cd1badaf8379d864334a3

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94014

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[ShridharGoel]

This should be fine, and better than the previous behaviour

CC: @mountiny

[MelvinBot]

Proposal

Confidence: Medium-High on the root cause (code-traced, not runtime-reproduced). This is a deploy blocker for #94014, so it's worth deciding fix vs. revert quickly.

What is the root cause of that problem?

PR #94014 migrated the Initial value selector from an in-page <Modal> to a standalone @react-navigation route (DynamicReportFieldsInitialListValuePage.tsx).

The old <Modal> was not a deeplinkable route, so a browser refresh always dropped the user back on the Add field page. The new page is a real route, and the create-flow draft (WORKSPACE_REPORT_FIELDS_FORM_DRAFT) persists across refresh (it's a normally-persisted Onyx key, not evictable/cleared on reload). So on refresh the page reads a populated draft and only redirects to the Add field page when there are zero enabled list values:

const availableListValuesLength = (formDraft?.[INPUT_IDS.DISABLED_LIST_VALUES] ?? []).filter((d) => !d).length;
const shouldRedirectToCreatePage = !isLoadingFormDraft && availableListValuesLength === 0;

(DynamicReportFieldsInitialListValuePage.tsx:45-46)

In this repro the list is [Alpha, Beta] with Alpha toggled off → DISABLED_LIST_VALUES = [true, false] → availableListValuesLength = 1 (Beta still enabled) → the guard is false → no redirect → the user stays on the Initial value page.

This guard was added for the #93138 regression, whose symptom was an empty picker (zero values). It only catches the all-disabled / no-values edge case — it does not restore the old "always return to Add field on refresh" behavior when one or more values remain enabled.

Why the simple #93138 flow looked "fixed" but this one isn't

#93138 was filed against the original (reverted) migration PR #91627, where the picker rendered before the draft loaded → empty picker. The #94014 fix added a loading state plus the zero-values redirect. With the draft persisting, a normal refresh now renders the picker correctly rather than redirecting — so the "return to Add field on refresh" expectation is only actually met in the genuinely-empty case. This toggle flow keeps Beta enabled, so it never hits that case.

Note: the Create-page menu item already clears a disabled initial value in-session via InitialListValueSelector/index.tsx:28-34, so the user-facing problem here is purely the navigation/landing behavior, not a stale stored value.

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

This page is a transient sub-step of the create flow, not a destination users should land on directly. It should redirect back to the Add field page whenever it's loaded as a fresh navigation (browser refresh / deeplink) — not only when the draft has zero enabled values. The persisted draft keeps name/type/list values intact, so the Add field page repopulates fully.

Concretely, broaden the redirect in DynamicReportFieldsInitialListValuePage so it also fires when the screen is the first/entry route of the session (no in-app navigation history into it), mirroring the original <Modal> behavior. The existing availableListValuesLength === 0 check can remain as a subset of that.

If a clean fix can't land before deploy: revert #94014, which is the source of this regression.

What alternative solutions did you explore? (Optional)

• Keep current behavior (stay on the page) and treat the tester's expectation as outdated — not recommended, since the migration changed long-standing refresh behavior and this is a flagged deploy blocker.

---

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