[HOLD for payment 2025-02-07] [$250] Wallet - "It's not here" error is briefly shown when deactivating a virtual card

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number:
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team
Slack conversation (hyperlinked to channel name):

Action Performed:

Precondition: Use a Gmail member account that has a single assigned virtual Expensify Card.

1. Navigate to https://staging.new.expensify.com/
2. Log in
3. Navigate to Settings - Wallet
4. Click on the card under "Assigned cards"
5. Click on "Report virtual card fraud"
6. Click on the "Deactivate card" button
7. Input the magic code

Expected Result:

I should be getting a proper error message at the bottom of the RHP.

Actual Result:

"It's not here" error is briefly shown when deactivating a virtual card.

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• [z] MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6689664_1733809758992.bandicam_2024-12-10_06-43-16-080.mp4

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021867191340390551829
• Upwork Job ID: 1867191340390551829
• Last Price Increase: 2024-12-12

Issue Owner

Current Issue Owner: @JmillsExpensify

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (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.

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @alitoshmatov (External)

[beodw]

@izarutskaya Video of reproducing bug is not playing.

[mountiny]

@koko57 would you want to work on this?

[truph01]

Proposal

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

• "It's not here" error is briefly shown when deactivating a virtual card.

What is the root cause of that problem?

• After step 7, we call:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 67 in 258e2be

Card.reportVirtualExpensifyCardFraud(virtualCard, validateCode);

It will set the card data to null:

App/src/libs/actions/Card.ts

Line 55 in 258e2be

[cardID]: null,

and then call:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 109 in 258e2be

Card.clearCardListErrors(virtualCard.cardID);

which will set the card data to {isLoading: false}.

• As a result, when the API is still processing, the card data is {isLoading: false}.

• When the API is finished, we have a logic to navigate the user back to the previous screen once the API is finished:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 59 in 258e2be

Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAINCARD.getRoute(cardID));

the navigation action needs time to process. Meanwhile, we display the not found page since BE has set the card data to null:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Lines 84 to 86 in 258e2be

	if (isEmptyObject(virtualCard)) {
	return <NotFoundPage />;
	}

• It is why the "It's not here" screen is briefly shown when deactivating a virtual card.

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

• We can introduce a state [isNavigating, setIsNavigating] = useState(false) and when isNavigating is true, display the fullscreen loading indicator:

    if (isNavigating) {
        return <FullScreenLoadingIndicator />;
    }

• The isNavigating will be set to true after line:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 59 in 258e2be

Navigation.navigate(ROUTES.SETTINGS_WALLET_DOMAINCARD.getRoute(cardID));

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

What alternative solutions did you explore? (Optional)

• Instead if display the loading indicator, we can update two conditions:

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 84 in 258e2be

if (isEmptyObject(virtualCard)) {

to:

    if (isEmptyObject(virtualCard) && !isNavigating) {

and

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 100 in 258e2be

isLoading={formData?.isLoading}

to:

                    isLoading={formData?.isLoading || isNavigating}

[burczu]

Hi! I'm Bartek from Callstack - expert contributor group. I’d like to work on this issue (if you decide to decline the above proposal, of course).

[melvin-bot]

@JmillsExpensify, @mountiny, @alitoshmatov Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[alitoshmatov]

@truph01 Thank you for your proposal. In your RCA you are mentioning that isLoading will be set to false even if request hasn't been completed, so I think this is a valid root cause. But I think your solution is ignoring this root cause and applying workaround

[alitoshmatov]

@truph01 Correction: Okay I think isLoading is not the related at all, it is working just fine. Loading is shown when API is being processed and when api resolves successfully, the page starts navigating, while it is navigating, for a brief time not found page is shown.

Edit:

We can introduce a state [isNavigating, setIsNavigating] = useState(false) and when isNavigating is true, display the fullscreen loading indicator:

We already have a loading button, we don't want to introduce another loading screen just to appear for a small amount of time when navigation is happening
Your alternative solution breaks the app, since virtualCard is used in a other places

[alitoshmatov]

Based on C+ doc, since existing proposal is not selected we can assign @burczu to this issue and wait for their proposal

cc: @JmillsExpensify @mountiny

[truph01]

Your alternative solution breaks the app, since virtualCard is used in a other places

@alitoshmatov Thanks for your feedback! I have a question regarding your point above: Why do you think my alternative solution would break the app? It simply shows a loading state in the button during navigation.

[alitoshmatov]

@truph01 Did you tested your alternative solution?

App/src/pages/settings/Wallet/ReportVirtualCardFraudPage.tsx

Line 109 in 919c59d

Card.clearCardListErrors(virtualCard.cardID);

We have a usage of virtualCard here. To be fair this small issue and could be fixed easily. But I am still in doubt about isNavigating state, I haven't seen similar use case in other places

[truph01]

@alitoshmatov

To be fair this small issue and could be fixed easily

• Ah, I see your point, and I agree that it’s a minor issue.

I am still in doubt about isNavigating state, I haven't seen similar use case in other places

• A similar approach was actually used in this PR:

App/src/pages/settings/Profile/CustomStatus/StatusPage.tsx

Lines 93 to 95 in a5913b9

	if (navigateBackToPreviousScreenTask.current) {
	return;
	}

[narefyev91]

Perhaps we wait until the other PR is merged and then we can revisit and see if we are still getting the issue? @narefyev91 can you confirm if your PR would fix this bug or not?

Yeah - based on my testing - not found page is not shown any more

[shawnborton]

Ah okay - so @JmillsExpensify @mountiny maybe we close this then?

[burczu]

@shawnborton I don't think we should close this issue - the other PR only fixes the problem with redirecting to the wrong page after card deactivation. In this issue we are changing the flow of the card deactivation and adding the confirmation page to improve UX as @mountiny proposed in this comment (and fixing this issue as a side effect).

I see the PR from @narefyev91 is already merged so I'll sync with it and check how it affects this issue.

[shawnborton]

Sounds good, that works for me - thanks for the gut check here.

[burczu]

@mountiny @alitoshmatov I've synced with the changes from this PR, and it looks like it does not interfere with my changes so I'm keeping the proposal as it is. Especially we need to keep the cardID stored in the ONYXKEYS.CARD_LIST key solution because the use of usePrevious hook from the other PR does not work: in our case we need to show additional modal with confirmation and it causes extra re-render so the previous virtualCard value is lost.

Regarding this comment: #53996 (comment) this is fixed by the other PR so once we get back to this page, it is correctly populated with new card details.

That being said, can I proceed with the PR now?

[mountiny]

Thanks for the discussion, I believe you can move ahead now if I understood everything right

[burczu]

The PR is now ready for review.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.92-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• Add report fraud confirmation page when getting new virtual card #55278

If no regressions arise, payment will be issued on 2025-02-07. 🎊

For reference, here are some details about the assignees on this issue:

• @burczu does not require payment (Contractor)
• @alitoshmatov requires payment through NewDot Manual Requests

[melvin-bot]

@alitoshmatov @JmillsExpensify @alitoshmatov The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button]

[mountiny]

This will be ready to pay out