[$250] Android & iOS - Expensify Card - Previous data is not cleared when issuing new card

[IuliiaHerets]

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: 9.0.69-1 Reproducible in staging?: Y Reproducible in production?: N If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: Exp https://expensify.testrail.io/index.php?/tests/view/5285123 Email or phone of affected tester (no customers): [email protected] Issue reported by: Applause Internal Team

Action Performed:

Precondition:

• Expensify Card is set up.

Issue 1:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Members.
3. Tap on any member.
4. Tap New card.
5. Go through card issue flow and remember all the details.
6. After issuing the card, tap New card to issue another card.
7. Go through the card issue flow.
8. Note that the previous data entered in Step 5 is preserved and not reset.

Issue 2:

1. Go to staging.new.expensify.com
2. Go to workspace settings > Expensify Card.
3. Tap Issue card.
4. Go through card issue flow.
5. After issuing the card, tap Issue card to issue another card.
6. Note that app shows the confirmation page from the previous card assignment instead of starting the flow with Step 1.

Expected Result:

When starting another card issue flow after issuing a card, the previous data will be cleared (production behavior).

Actual Result:

When starting another card issue flow after issuing a card, the previous data is preserved.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

https://github.com/user-attachments/assets/4582ba10-6697-48e5-9560-49aa66b529fa

https://github.com/user-attachments/assets/3acadcb3-bd8b-4f64-89b2-93edb68b70d8

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @

Issue Owner

Current Issue Owner: @koko57

[melvin-bot[bot]]

Triggered auto assignment to @kadiealexander (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[bot]]

Triggered auto assignment to @Julesssss (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot[bot]]

💬 A slack conversation has been started in #expensify-open-source

[github-actions[bot]]

:wave: 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.

[koko57]

I can take a look

[Julesssss]

Ah, thanks Vit. I will unsub

[allgandalf]

@koko57 were you able to reproduce the 1st bug ?

[koko57]

@allgandalf I tested on web while my ios app is building - I cannot repro the first issue - after successfully issuing a card while I'm going through the flow I need to provide the new data BUT of course on Step 5 I will get the same value when issuing a physical card again - because we always default to "User's card"

but I wonder if it's only the mobile issue? TBH it should work the same

[allgandalf]

@mountiny was mentioning that we have not deployed native platforms since last 2 deploys. So there would be mismatch between web and native

[allgandalf]

I am getting a lot of mixed results here, I was able to reproduce the 1st one partially, I saw the value persisted but it went away in like ~2 seconds, and now i cannot reproduce it anymore

[koko57]

yet still there weren't any changes applied (that I'm at least aware of) that could cause such problem.

[koko57]

Ok, I was able to reproduce it. Digging now

[koko57]

Straaange, bc we are clearing the data from Onyx

• is there anything I don't see in these logs?

[mountiny]

I have demoted as the users are not blocked from adding cards, adding to the expense projectš and exporting

[melvin-bot[bot]]

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

[melvin-bot[bot]]

Current assignee @allgandalf is eligible for the External assigner, not assigning anyone new.

[koko57]

@mountiny I'm back I can continue working on that

[mountiny]

thanks!

[koko57]

craaaazy - when I add this to success data for issueExpensifyCard after the request is sent and we get the response - the confirmation step is displayed and the data is still there 😱 something's very very strange here, I will continue digging

[koko57]

btw I've noticed that the Verify Magicode Modal's submit button is a little bit higher than the submit button of each step of the flow (I think they should be in the same position, shouldn't they?)

@mountiny I've search through the issues but I haven't found any like this - maybe we can create a new one? I don't want to fix it here as it's necessary to check how it's aligned with the other flows that this modal is used in and maybe if it's necessary make it consistent everywhere. Ofc I'm a volunteer to take this one 🙋🏻‍♀️

cc @shawnborton @dubielzyk-expensify

[shawnborton]

I think they should be in the same position, shouldn't they?

Agree, they should be identical.

[mountiny]

Yeah that will be from the edge-to-edge feature enablement cc @kirillzyusko

[mountiny]

Created an issue for that to keep the concerns separated https://github.com/Expensify/App/issues/53583

[ikevin127]

I looked into this briefly when it still had the Help Wanted label and here's what I found:

• I think the issue might have something to do with the fact that for some reason, on native devices, the IssueNewCardPage and some of the steps seem to mount multiple times as one goes through each step
• after adding a card and being navigated back to the cards list, when clicking New card which opens a modal with the steps -> some of the steps are still mounted from the previous instance, causing old data to be pushed to onyx again

What I found unusual is that I noticed we call Card.clearIssueNewCardFlow() in 3 different places which still does not seem to clear the data (this issue) as intended:

• in IssueNewCardPage only on unmount:

https://github.com/Expensify/App/blob/f3a128d30097926b0305d7a84580f6d39daaa5c4/src/pages/workspace/expensifyCard/issueNew/IssueNewCardPage.tsx#L33-L37

• on AssigneeStep in handleBackButtonPress:

https://github.com/Expensify/App/blob/f3a128d30097926b0305d7a84580f6d39daaa5c4/src/pages/workspace/expensifyCard/issueNew/AssigneeStep.tsx#L59-L66

• on ConfirmationStep when isSuccessful is true and after calling navigate back to cards list:

https://github.com/Expensify/App/blob/f3a128d30097926b0305d7a84580f6d39daaa5c4/src/pages/workspace/expensifyCard/issueNew/ConfirmationStep.tsx#L56-L62

A solution that worked in fixing the issue was to add Card.clearIssueNewCardFlow() in IssueNewCardPage once when the component mounts - while this solution fixes the issue, as mentioned above I think there are deeper issues with the flow that need to be addressed regarding mount / unmount behaviour and multiple calls of Card.clearIssueNewCardFlow().

Hope this helps in fixing the issue.

[koko57]

Thanks for the hint, I will check it out!

[koko57]

I cannot confirm this

the IssueNewCardPage and some of the steps seem to mount multiple times as one goes through each step @ikevin127 how were you able to find out that?

A solution that worked in fixing the issue was to add Card.clearIssueNewCardFlow() in IssueNewCardPage once when the component mounts

this one works, but unfortunately it breaks the flow from the member's page - skipping Assignee Step with assignee already assigned - we land on the Assignee Step.

[ikevin127]

skipping Assignee Step with assignee already assigned

This could be fixed with checking if Assignee exists and clearing all data except Assignee such that it would go to the next step and not break that flow.

[melvin-bot[bot]]

@koko57, @mountiny, @kadiealexander, @allgandalf Whoops! This issue is 2 days overdue. Let's get this updated quick!

[koko57]

no, it still doesn't work like intended, but I've just found something that might be the root cause of the problem, so maybe we won't need such a workaround

[koko57]

Looks like clearIssueNewCardError runs after clearIssueNewCardFlow and as we pass issueNewCard from the confirmation step as an argument and it's used to set the new issueNewCard object we end up with the old object in the new flow, removing this param fixes the problem. This hasn't occurred before the introduction ValidateCodeActionModal.