Workspace - Unlock feature is briefly visible after adding a bank account and unlocking all features

[isagoico]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Found while QAing #5642

Action Performed:

1. Navigate to a workspace in a account that does not have a bank account added
2. Check all the options and verify you're blocked from most of them until you add a bank account
3. Add a fully verified bank account
4. Navigate to the same options you were blocked before.

Expected Result:

Features should be unblocked and no visual issue should be present.

Actual Result:

The blocked feature text is visible for a brief moment.

Workaround:

Unknown .

Platform:

Where is this issue occurring?

• Web
• iOS
• Android
• Desktop App
• Mobile Web

Version Number: 1.1.7-3

Reproducible in staging?: yes
Reproducible in production?: no

Logs: https://stackoverflow.com/c/expensify/questions/4856

Notes/Photos/Videos: Any additional supporting documentation

Screen_Recording_20211011-152409_New.Expensify.mp4

Expensify/Expensify Issue URL:

Issue reported by: Applause
Slack conversation:

View all open jobs on GitHub

[MelvinBot]

Triggered auto assignment to @Gonals (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

[OSBotify]

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

[tgolen]

Ah, I know why this happens. It's because in order to make the pages available even when you're offline, they are showing whatever data is in Onyx first, then calling the API to load the latest bank account information, then the page will update with the new data. This all happens here:

App/src/pages/workspace/WorkspacePageWithSections.js

Line 49 in df2b2d8

fetchFreePlanVerifiedBankAccount();

The alternative was to show a loading indicator while the API call is being done, but then that wouldn't work in offline mode (ie. you'd see a loading indicator until the app came back online).

What we should possibly consider doing is calling fetchFreePlanVerifiedBankAccount() at the very end of the banking flow (I'm not very sure where this happens, but @marcaaron knows). That way, by the time the API call is finished, the data will have loaded into Onyx before someone goes to those other pages.

[tgolen]

Oh, another idea instead of making multiple API calls is to just ensure that reimbursementAccount.achData.state is 'OPEN' in Onyx at the end of the VBA flow.

[kevinksullivan]

@tgolen I noticed you mention this is tied in with offline mode, where we're seeing a similar issue, so figured I'd drop it here to start. After enabling the cards I will see Cards are ready! and all correct copy, but if I go offline, the page will flip back to Unlock free expensify cards, and all pages will show copy as if I don't have the card.

Is this problem/potential solution related to the issue we're seeing here on loading the pages so they show correct copy? Or do you suggest we get this in a separate issue?

[Gonals]

WorkspacePageWithSections.js

I think the issue is a bit different. This doesn't happen the first time those sections are open after adding the bank account. It happens every time.

The cause seems to be this line in fetchFreePlanVerifiedBankAccount. We reset the status every time in Onyx for a little bit, when the function is called, so the display changes for a bit.

I think we can fix this simply by checking ONYX first and, if we already have an OPEN account there, not calling fetchFreePlanVerifiedBankAccount. I'm pretty sure we set the status correctly at the end of the process, so it should be fine.

I'll do some testing with that and see if it causes any issues when the bank account is deleted from oldDot.

[Gonals]

WorkspacePageWithSections.js

I think the issue is a bit different. This doesn't happen the first time those sections are open after adding the bank account. It happens every time.

The cause seems to be this line in fetchFreePlanVerifiedBankAccount. We reset the status every time in Onyx for a little bit, when the function is called, so the display changes for a bit.

I think we can fix this simply by checking ONYX first and, if we already have an OPEN account there, not calling fetchFreePlanVerifiedBankAccount. I'm pretty sure we set the status correctly at the end of the process, so it should be fine.

I'll do some testing with that and see if it causes any issues when the bank account is deleted from oldDot.

Yep, as I expected, we get issues if the account gets deleted in oldDot. The behavior remains as if the account were open until we refresh.
Trying something else after lunch!

[Gonals]

Fix in place! Do we still consider this a deployblocker? It is a visual bug, but it doesn't break stuff.

[marcaaron]

Oh, another idea instead of making multiple API calls is to just ensure that reimbursementAccount.achData.state is 'OPEN' in Onyx at the end of the VBA flow.

We do this already I think and it should happen after BankAccount_Validate. There's some logic here:

App/src/libs/actions/BankAccounts.js

Lines 574 to 587 in 5302984

	const reimbursementAccount = {
	loading: false,
	error: '',
	achData: {state: BankAccount.STATE.OPEN},
	};
	if (isUsingExpensifyCard) {
	Navigation.dismissModal();
	} else {
	reimbursementAccount.achData.currentStep = CONST.BANK_ACCOUNT.STEP.ENABLE;
	}
	Onyx.merge(ONYXKEYS.USER, {isUsingExpensifyCard});
	Onyx.merge(ONYXKEYS.REIMBURSEMENT_ACCOUNT, reimbursementAccount);

[marcaaron]

Could we maybe just hide the options until !reimbursementAccount.loading when we fetch the bank account here?

App/src/pages/workspace/WorkspacePageWithSections.js

Line 49 in 5302984

fetchFreePlanVerifiedBankAccount();

[tgolen]

Ah, yeah, we could. I think the solution in Alberto's PR is a pretty solid one though.

[marcaaron]

It's not bad and maybe even the longer term approach we want to go with. But it makes my stomach hurt a little since there are many things that might be expecting that data to be reset each time we fetch it. As long as we test heavily we should be good.

Mainly proposing the alternative solution because I can guarantee there will be no unintended side effects.

[tgolen]

OK, got it. Makes sense. I think the testing has been pretty thorough so far, so I have pretty high confidence that we should be able to catch any issues in the flow if they are introduced.