[$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 contributors@expensify.com 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: @alitoshmatov

[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;
	}

[mountiny]

@burczu please go ahead

[burczu]

Proposal

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

The "It's not here" 404 page is shown for a short period of time after successfully deactivating a virtual card and before redirecting back.

What is the root cause of that problem?

To root cause of the problem is that we rely on existence of the virtual card inside the list of cards when deciding if we need to show the "It's not there" page or not:

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

Lines 84 to 86 in c45f834

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

where the virtualCard variable is defined here (the cardID is taken from the route):

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

Line 41 in c45f834

const virtualCard = cardList?.[cardID];

The problem is, that when we call the ReportVirtualExpensifyCardFraud API action, it sets the cardList?.[cardID] to null in response (we even set it like that optimistically). This causes the short period of time between the API response and starting the redirect back to the card page, where the condition to show the 404 page is fulfilled.

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

To prevent this, we could store the copy of the cardList?.[cardID] initial value inside the ref, and rely on it in the condition:

const virtualCard = cardList?.[cardID];
const virtualCardRef = useRef(virtualCard);

...


if (isEmptyObject(virtualCardRef?.current)) {
    return <NotFoundPage />;
}

Thanks to these changes, we prevent showing the 404 error page after the API call is successful, even that the card is already removed from the list of cards. And it will still work for the original purpose of this part of code - if we open the page with incorrect cardID the 404 page will be presented.

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

What alternative solutions did you explore? (Optional)

n/a

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.

[mountiny]

@alitoshmatov thoights?

[mountiny]

@burczu does this also mean that if i am looking at the page as admin 1 and admin 2 deactivates this card, the pusher event will come in but i as admin 1 will still see the card as if it was not deleted?

[burczu]

@mountiny Hmm... I didn't consider this scenario... I'll test it today and if it is the case, I'll work on addressing it.

[mountiny]

I am not sure if its critical, these dynamic bugs are hard to handle, but feels like this might be the case with the prosed changes

[alitoshmatov]

I am not sure why but I don't think this approach is correct, we shouldn't have a copy of data just for the sake of solving slow navigation. If we needed it, then we should have set up our logic so that data be deleted after navigation happens.

Also if data is set to null optimistically why wait for api request, based on the code shouldn't NotFoundPage be shown immediately.

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

Lines 84 to 86 in 0bf6d8c

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

[burczu]

@alitoshmatov Even without setting it optimistically, its the API response that sets it to null which is also too early. At first I was trying to rely on the isLoading property and postponing changing it to false on the page we are navigating to (by adding additional query string parameter to the URL) but without success - it looks like we need to wait not only for navigation action to be finished, but also the navigation animation...

[burczu]

@mountiny I think the scenario you was worrying about is impossible - from what I see, every user can report fraud only of its own cards in the wallet, so it's impossible that another admin can see the same report fraud page at the same time. But maybe I'm missing something?

[burczu]

@alitoshmatov I've tried removing optimistically clearing card data in the list of cards but it does not fix the issue - the 404 page still shows up, but for shorter period.

I've also gave a try once again the solution I've described in my previous comment but unfortunately without success - the navigation finishes earlier than the animation so the 404 page is visible for some short time.

I think, as we can't react to the end of the animation (at least I couldn't find the way to do it), the only solution must be kinda hack-ish - I agree it's not perfect. If we don't like storing the copy of the data inside the ref, we could think of storing it in Onyx, under the REPORT_VIRTUAL_CARD_FRAUD key. What do you think?

[melvin-bot]

Auto-assign attempt failed, all eligible assignees are OOO.

[mountiny]

I kind feel like this flow is a bit weird

When i actually want to report fraud on my card, i am probably worried about abuse of the card. I would like to get clear feedback the card was successfully terminated and it could not be abused by anyone.

@JmillsExpensify @Expensify/design what do you this about showing some success screen after the card is deactivated? This would provide clear feedback to the user and fix this bug as well.

We could also further improve the success screen by directly adding not only "ok" button, but a CTA to create a new card (if you are admin)

What do you think?

[melvin-bot]

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

[melvin-bot]

@JmillsExpensify @burczu @mountiny @alitoshmatov this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!