[Due for payment 2026-03-30] Expensify Card - Not all address fields are updated after changing address on confirm page

[jponikarchuk]

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.3.37-9
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #84844
Email or phone of affected tester (no customers): applausetester+sjddjois2j1d@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Other

Action Performed:

Precondition:

• User does not have address filled in Private details
• User is assigned a physical Expensify Card.

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Click Add shipping details.
4. Enter name, date of birth, US address, phone number and reach the confirm page.
5. On confirm page, click Address field.
6. Select address from another country (eg, Delhi - Mumbai Expressway).
7. Click Confirm.
8. Click RHP back button twice.

Expected Result:

All the address fields will be updated.

Actual Result:

Only Address line, City and Zip are updated.
Country and State field are not updated.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @bernhardoj

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #84844 - "Update the input whenever the draft is updated" by @bernhardoj (High confidence)
Related Issues: Fixes #84475

Recommendation: REVERT

This PR attempted to fix a similar form state synchronization issue but introduced a new regression. The change moved draft value synchronization from useEffect to render-time execution, which causes improper state updates and violates React best practices.

Labels: DeployBlockerCash will remain (frontend bug affecting App)

📋 Detailed Analysis

Evidence

PR #84844 modified src/components/Form/FormProvider.tsx to change how draft values are synchronized with form input values. The PR was merged on March 12, 2026 and is part of the staging deploy 9.3.37-9.

The issue is:

• Reproducible on staging: Yes (where PR Update the input whenever the draft is updated #84844 is deployed)
• Reproducible on production: No (PR not yet in production)
• This directly correlates with PR Update the input whenever the draft is updated #84844 being in the current staging deploy.

Verification

Files affected by the bug:

• /home/runner/_work/App/App/src/components/Form/FormProvider.tsx - Modified by PR Update the input whenever the draft is updated #84844
• /home/runner/_work/App/App/src/pages/MissingPersonalDetails/subPages/Address.tsx - Uses the FormProvider
• /home/runner/_work/App/App/src/pages/MissingPersonalDetails/subPages/Confirmation.tsx - Confirmation page where editing occurs

Confirmed that PR #84844 modified FormProvider.tsx, changing the core logic for syncing draft values.

Root Cause

PR #84844 changed the draft value synchronization logic in FormProvider:

OLD code (working):

const prevIsLoadingDraftValues = usePrevious(isLoadingDraftValues);

useEffect(() => {
    if (isLoadingDraftValues || !prevIsLoadingDraftValues) {
        return;
    }
    setInputValues({...draftValues});
}, [isLoadingDraftValues, draftValues, prevIsLoadingDraftValues]);

NEW code (broken):

const previousDraftValues = useRef(draftValues);

if (!isLoadingDraftValues && draftValues !== previousDraftValues.current) {
    previousDraftValues.current = draftValues;
    setInputValues({...inputValues, ...draftValues});
}

The problems with the new code:

1. Render-time setState: The new code calls setInputValues during render (not in useEffect), which violates React best practices and can cause unexpected behavior.

2. Stale closure: Using inputValues in the setState call during render can capture stale state, especially when multiple state updates happen in quick succession.

3. Incomplete merge: While {...inputValues, ...draftValues} should theoretically override old values, the render-time execution and stale closures can cause the Country and State fields to not update properly when address changes trigger multiple field updates simultaneously.

When a user:

1. Fills in US address (country="US", state="CA")
2. Reaches confirmation page
3. Clicks to edit address field
4. Selects a non-US address (e.g., India)
5. Confirms and goes back

The AddressSearch component updates multiple fields at once (addressLine1, city, state, country, zipCode). The render-time setState in the new code cannot properly handle this multi-field update, causing Country and State to show stale values while other fields update correctly.

Additional Context

The original issue #84475 that PR #84844 tried to fix was about NetSuite custom list forms not showing updated values. However, the fix introduced this new regression in a different form (Expensify Card shipping details).

As noted in the comments on issue #84475, this approach of using setState during render violates React guidelines: https://react.dev/learn/you-might-not-need-an-effect#adjusting-some-state-when-a-prop-changes

[cristipaval]

I'm demoting this one, it seems rare and doesn't block the functionality