The "Getting started" section disappears from Home before all to-dos are complete

[applause-bot]

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: v9.4.21-2
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94047
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Android 13 / Xiaomi Poco F5
App Component: Other

Action Performed:

1. Navigate to https://staging.new.expensify.com/
2. Sign up a new account and select the onboarding intent is Manage my team's expenses
3. Complete the onboarding flow
4. Complete the Customize accounting categories by editing any Category name
   Verify that the Customize accounting categories is checked and the new to-do Set up spend rules appears
5. Complete the Link company cards by adding a company card
6. Back to Home section

Expected Result:

Verify the Getting started section disappears from Home once all to-dos are complete

Actual Result:

The "Getting started" section disappears from Home before all to-dos are complete.
Note:

• The to-do Set up spend rule is still not completed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7192780_1782556029035.94730_-_PR94047_-_The_Getting_started_section_disappears_from_Home_before_all_to-dos_are_complete.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7192780

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/8c6bb12bac5a890c2dc8b289af2e95ff12c7a7d46f93b23d8ee71f20da302f89

[melvin-bot]

@grgia recently merged #94047, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

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

[MelvinBot]

Proposal

Deploy-blocker recommendation: the fastest safe unblock is to revert Expensify/App#94047 (the PR that introduced this), which restores the prior behavior where the section stays for the Getting Started window. The hide logic can then be re-landed with the fix below.

What is the root cause of that problem?

PR #94047 added a buildResult helper that hides the entire Getting started section as soon as every item currently in the list is complete:

useGettingStartedItems.ts:65-70

The problem is that the Set up spend rules to-do is conditional — it's only pushed into the list when policy.areRulesEnabled is true:

useGettingStartedItems.ts:156-163

So when areRulesEnabled is false/not-yet-loaded for a given render — which happens transiently while the policy is being merged/refetched (e.g. right after completing Link company cards) — the setupRules item is absent from the array. The remaining items (createWorkspace, customizeCategories, linkCompanyCards) are then all complete, items.every(isComplete) returns true, and the whole section collapses, even though the user still has an outstanding "Set up spend rules" to-do. That matches the report exactly: the section vanishes while Set up spend rule is still incomplete.

Investigation details & a second contributing factor

Why the item disappears: areRulesEnabled is only written by enablePolicyRules / the Control upgrade flow — not by completing categories or company cards (verified: enablePolicyCategories and enableCompanyCards never touch it). In the repro, the to-do appeared after the category edit (rules got enabled by a separate/optimistic update), but a subsequent policy merge (adding the company card) can land a render where areRulesEnabled is momentarily false, dropping setupRules from the list and triggering the premature every() hide.

Second, independent flaw in the completion check: even when setupRules is present, its isComplete uses hasConfiguredRules(policy), which returns true on auto-enabled fields the user never configured — notably policy.eReceipts (auto-set to true for Control + USD workspaces when rules are enabled) and requireCompanyCardsEnabled. On such a workspace the "Set up spend rules" to-do can auto-complete with zero user action, also collapsing the section prematurely. Whichever path fires first, the result is the same.

Alternative explanations ruled out: a logic bug where setupRules is present and incomplete would keep the section visible (every → false) — that path is correct. The bug only manifests when the item is either absent (race) or auto-completed (hasConfiguredRules).

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

Don't derive "all to-dos done" from a list whose membership depends on async/optimistic policy flags. Concretely:

1. Build the full, stable set of to-dos for the intent before evaluating completeness — i.e. always include the setupRules to-do for the rules-eligible intents rather than gating its existence on the live areRulesEnabled flag, and/or guard buildResult so it doesn't hide while required policy data (policy, card feeds, rules flag) is still loading.
2. Fix hasConfiguredRules (or use a narrower check for this to-do) so the "Set up spend rules" item is only considered complete when the user has actually configured a rule — not when eReceipts/requireCompanyCardsEnabled were auto-enabled by the Control upgrade.

What alternative solutions did you explore? (Optional)

Revert #94047 to immediately unblock the deploy (recommended for the deploy-blocker), then re-land with the guard above plus a unit test covering: areRulesEnabled toggling false→true across renders, and a Control+USD workspace where eReceipts is auto-set.

Confidence: Medium — the buildResult design flaw and the hasConfiguredRules over-matching are confirmed in code; the exact production render ordering of areRulesEnabled (which involves a Web-Expensify policy response outside this repo) would be worth confirming from logs but doesn't change the App-side fix.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94773) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.