[Due for payment 2025-10-31] [$250] iOS - Expensify card - "Deactivate card" and "Let's make sure it's you" shown briefly for a new card

[vincdargento]

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.2.16-8
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #68425
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: iPhone 15 iOS 18.5
App Component: Other

Action Performed:

1. Sign in to ND
2. Set up the Expensify card feature
3. Assign a virtual card to yourself, then deactivate the card
4. Start issuing a virtual card to yourself again
5. On confirmation page tap "Issue card"
6. Enter a verification code - the "Deactivate card" modal is shown briefly
7. Navigate to the Expensify card tab, open the card details and tap "Deactivate card" - "Let's make sure it's you" page appears briefly

Expected Result:

After deactivating Expensify card and issuing a new one "Deactivate card" does not appear briefly after confirming the account. "Let's make sure it's you" does not appear briefly after deactivating the new card.

Actual Result:

After deactivating Expensify card and issuing a new one "Deactivate card" appears briefly after confirming the account. "Let's make sure it's you" appears briefly after deactivating the new card.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

bug.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021971638822824565615
• Upwork Job ID: 1971638822824565615
• Last Price Increase: 2025-09-26
• Automatic offers:
• nkdengineer | Contributor | 108960793

[melvin-bot]

Triggered auto assignment to @heyjennahay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[Eskalifer1]

Proposal

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

iOS - Expensify card - "Deactivate card" and "Let's make sure it's you" shown briefly for a new card

What is the root cause of that problem?

The error occurs due to a race condition in navigation, as a result of which the modal window does not have time to close and we already move to another page:

App/src/pages/workspace/expensifyCard/WorkspaceExpensifyCardDetailsPage.tsx

Lines 95 to 101 in 1fada27

	const deactivateCard = () => {
	setIsDeleted(true);
	setIsDeactivateModalVisible(false);
	requestAnimationFrame(() => {
	Navigation.goBack();
	});
	};

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

We need to break down navigation step by step, rather than all at once. This can be done as follows:

    const deactivateCard = () => {
        InteractionManager.runAfterInteractions(() => {
            setIsDeleted(true);

            requestAnimationFrame(() => {
                Navigation.goBack();
            });
        });
        setIsDeactivateModalVisible(false);
    };

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

N/A

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.

[abzokhattab]

Proposal

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

Brief modal appearances ("Deactivate card" and "Let's make sure it's you") when navigating between Expensify card flows after deactivating and issuing new cards.

What is the root cause of that problem?

• Modal states (isDeactivateModalVisible, isOfflineModalVisible, isUnassignModalVisible) are not reset when components mount
• When users navigate between card flows, these states can persist from previous interactions
• This causes modals to briefly flash before being properly hidden

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

• Add useEffect hooks to reset modal states to false when components mount
• Apply this fix to both WorkspaceExpensifyCardDetailsPage.tsx and WorkspaceCompanyCardDetailsPage.tsx
• Ensure modal states are always properly initialized regardless of navigation history

// WorkspaceExpensifyCardDetailsPage.tsx
    useEffect(() => {
        setIsDeactivateModalVisible(false);
        setIsOfflineModalVisible(false);
    }, []);

// WorkspaceCompanyCardDetailsPage.tsx
    useEffect(() => {
        setIsUnassignModalVisible(false);
    }, []);

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

NA

What alternative solutions did you explore? (Optional)

NA

[nkdengineer]

Proposal

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

After deactivating Expensify card and issuing a new one "Deactivate card" appears briefly after confirming the account. "Let's make sure it's you" appears briefly after deactivating the new card.

What is the root cause of that problem?

This issue happens because of the race condition, when users confirm deactivate card, we'll hide the modal and navigate back

App/src/pages/workspace/expensifyCard/WorkspaceExpensifyCardDetailsPage.tsx

Lines 95 to 101 in 1fada27

	const deactivateCard = () => {
	setIsDeleted(true);
	setIsDeactivateModalVisible(false);
	requestAnimationFrame(() => {
	Navigation.goBack();
	});
	};

so the react state is not cleared correctly while processing 2 animations at the same time

we already had the logic to delay navigate back by using requestAnimationFrame, but it's not enough and it seems like the workaround

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

We shouldn't lean on requestAnimationFrame, instead we will trigger Navigation.goBack(); only when the modal hide

Add

onModalHide={() => {
                            Navigation.goBack();
                        }}

to ConfirmModal

and remove these lines

We already used this logic in other places like AttachmentModal, ...

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

None

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.

[melvin-bot]

@heyjennahay Whoops! This issue is 2 days overdue. Let's get this updated quick!

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021971638822824565615