Private Setting- Unverified personal details kept in personal detail 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: 9.4.0-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #91646
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 pro /Chrome
App Component: User Settings

Action Performed:

1. Navigate to staging.new.expensify.com
2. Go to Account page >Profile > private section
3. Fill every personal detail page and save
4. Enter magic code
5. Go back to detail page and change country and Zip code > Save
6. Tap back button in validation page > back again
7. Notice the change is not reflected in private section
8. Open the RHP
9. Notice the change is

Expected Result:

The change should not be applied as the change is not validated.

Actual Result:

The change is saved in RHP private detail page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7172925

[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/855e7d0328470819b44ac64a2fd88cfef066a0240094d63f555a3935cef44671

[melvin-bot]

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

[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.

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Private Setting- Unverified personal details kept in personal detail page

What is the root cause of that problem?

I traced this to the path that handles the issue-specific state:

• src/pages/AddPersonalBankAccountPage.tsx:34 (closeRHPFlow): Navigation.closeRHPFlow();
• src/pages/MissingPersonalDetails/MissingPersonalDetailsContent.tsx:143 (closeRHPFlow): Navigation.closeRHPFlow();
• src/pages/home/ForYouSection/index.tsx:52 (navigate): Navigation.navigate(ROUTES.EXPENSE_REPORT_RHP.getRoute({reportID, backTo: ROUTES.HOME}));
• The local evidence matches this recurring failure shape: route params are created in one format and read in another. Here, src/pages/AddPersonalBankAccountPage.tsx:34 and src/pages/MissingPersonalDetails/MissingPersonalDetailsContent.tsx:143 do not agree on the same the issue-specific state value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/AddPersonalBankAccountPage.tsx:34 to derive the issue-specific state from the route/access source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/MissingPersonalDetails/MissingPersonalDetailsContent.tsx:143; that follows the safer family move to fix the route builder/consumer pair instead of adding a screen-only redirect, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Navigation, RHP, Not Here, Back Stack surface and avoid changing deep links, auth/onboarding redirects.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/navigation/**/*.ts for the exact issue flow: Private Setting- Unverified personal details kept in personal detail page.
2. Cover the counter-case near src/pages/AddPersonalBankAccountPage.tsx:34 so valid existing the issue-specific state behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep the issue-specific state consistent at the first read/write boundary shown above.

[MelvinBot]

Issue Analysis

Root Cause: Unvalidated edits are stored only in the PERSONAL_DETAILS_FORM Onyx draft, never optimistically written to PRIVATE_PERSONAL_DETAILS. When the user backs out of the magic-code page, nothing clears that draft, so the RHP form re-seeds from it on remount — while the Profile summary (which reads the committed PRIVATE_PERSONAL_DETAILS) correctly shows the old value. The two views diverge.

The success path clears the draft, but the cancel/back path does not:

• Success: PrivatePersonalDetailsConfirmMagicCodePage.tsx:51 calls clearDraftValues(...).
• Cancel (Back): PrivatePersonalDetailsConfirmMagicCodePage.tsx:72-79 only calls Navigation.goBack() — the draft survives.

The parent page deliberately skips its own unmount-time draft clear when navigating to the magic-code RHP (PrivatePersonalDetailsPage.tsx:85-94) so the submission payload is preserved — but nothing reverses that when the user backs out.

Recommended Fix: Clear the form draft on the cancel/unmount path of the magic-code page so an unvalidated edit doesn't persist. A useEffect cleanup that fires on unmount unless submission succeeded is the most robust option (covers Back button, swipe-back, hardware back, and navigating away), since clearDraftValues is already imported in that file.

Investigation details & data flow

Cancel-path data flow:

1. User edits country + zip → each keystroke writes to personalDetailsForm draft (inputs use shouldSaveDraft).
2. Save → onSubmit writes the form to the draft, sets skipClearDraftOnUnmountRef = true, navigates to the magic-code RHP (PrivatePersonalDetailsPage.tsx:213-223).
3. Parent unmounts; cleanup bails on the ref → draft remains.
4. User taps Back → onClose only calls Navigation.goBack() → draft remains.
5. Parent remounts; FormProvider seeds inputs from the draft (FormProvider.tsx:150, 372-373), and the page's local selectedCountry/selectedState also seed from the draft (PrivatePersonalDetailsPage.tsx:77-80) → unvalidated values reappear.
6. Profile summary reads PRIVATE_PERSONAL_DETAILS directly with no draft fallback (ProfilePage.tsx) → shows the old value.

Why the committed value is never touched: updatePrivatePersonalDetails only writes {isLoading: true} optimistically to PRIVATE_PERSONAL_DETAILS; the field values are committed only by the backend response (PersonalDetails.ts:519-567). This is why only the draft-backed RHP form shows the stale edit.

Alternative explanation considered: an optimistic write to PRIVATE_PERSONAL_DETAILS leaking into the RHP — ruled out, since the action never writes the field values optimistically and the Profile summary (same source) is unaffected.

Suggested implementation (sketch):

const submittedSuccessfullyRef = useRef(false);
// in the existing success branch (line 48-53):
submittedSuccessfullyRef.current = true;
// new unmount effect:
useEffect(() => () => {
    if (submittedSuccessfullyRef.current) {
        return;
    }
    clearDraftValues(ONYXKEYS.FORMS.PERSONAL_DETAILS_FORM);
}, []);

Confidence: High — small, deterministic client-side lifecycle bug; the cleanup omission is directly visible by comparing the success effect (clears draft) with the cancel onClose (does not).

---

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

[jasperhuangg]

I don't think this is an issue, we discussed this in the PR review and landed on the form fields always preserving their last value, even if the user navigates to the validate code page and then closes the form.

the fix would be to clear PERSONAL_DETAILS_FORM_DRAFT in the magic-code page's onClose