Home - "Customize accounting categories" gets checked again after removing accountant

[jponikarchuk]

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: 9.3.68-1
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: #88607
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Other

Action Performed:

1. Open the Expensify app.
2. Sign up with a new account and select "Track and budget expenses" during onboarding.
3. Navigate to "Home"
4. Click on "Customize accounting categories"
5. Add a new category.
6. Return to "Home"
7. Note that "Customize accounting categories" is now checked.
8. Click on the same row again.
9. Delete the just added category and return to "Home"
10. Note that row is now unchecked.
11. Click on "Invite your accountant"
12. Invite a new member to workspace and return to "Home"
13. Note that "Invite your accountant" is now checked.
14. Click on the same row again and remove the just invited member.
15. Return to "Home"
16. Note that "Invite your accountant" is now unchecked, but "Customize accounting categories" is checked again.

Expected Result:

"Customize accounting categories" in "Getting Started" section should not be checked or unchecked after making editions on "Invite your accountant" row.

Actual Result:

"Customize accounting categories" row, gets unchecked after deleting added category, but gets checked again after making changes on "Invite your accountant" row.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #88607

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #88607 - "[Home Page] Add onboarding intent for Track and budget my expenses" by @adamgrzybowski (High confidence)
Related Issues: #88159

Recommendation: REVERT

PR #88607 introduced the TRACK_WORKSPACE onboarding flow, and the bug is isolated to the new code it added. Reverting this PR will remove the broken behavior without affecting any existing functionality.

Assigned: @adamgrzybowski (PR author), @ZhenjaHorbach (approving reviewer), @grgia (approving reviewer)
Labels: DeployBlockerCash kept (frontend App bug). No label changes were made.

Detailed Analysis

Evidence

• The melvin-bot comment on the issue directly attributes the bug to PR [Home Page] Add onboarding intent for Track and budget my expenses #88607.
• PR [Home Page] Add onboarding intent for Track and budget my expenses #88607 is listed in the StagingDeployCash checklist (Deploy Checklist: New Expensify 2026-05-06 #89819) for version 9.3.68-1, matching the version in the issue report.
• The issue is marked as "not reproducible in production / new feature" — confirming it was introduced by a staging PR.
• The bug manifests in the exact flow introduced by PR [Home Page] Add onboarding intent for Track and budget my expenses #88607: the TRACK_WORKSPACE onboarding intent path with the "Customize accounting categories" and "Invite your accountant" rows.

Verification

• Affected file: src/pages/home/GettingStartedSection/hooks/useGettingStartedItems.ts
• PR [Home Page] Add onboarding intent for Track and budget my expenses #88607 directly modifies this file (adding 26 lines), introducing the TRACK_WORKSPACE branch with the customizeCategories and inviteAccountant items.
• The isComplete state for customizeCategories is computed as hasCustomCategories(policyCategories), which returns false when all custom categories have pendingAction === DELETE (i.e., are optimistically pending deletion).

Root Cause

The customizeCategories item's completion state is driven by hasCustomCategories(policyCategories), which excludes categories whose pendingAction is DELETE. After the user deletes a custom category, the category is marked with pendingAction: DELETE optimistically, so hasCustomCategories correctly returns false and the row appears unchecked.

However, when the user subsequently navigates to the members page and removes an invited member, a subsequent API response or Onyx update refreshes the policyCategories collection. If the server-side delete of the category has not fully committed, or if the Onyx data is re-populated from a stale server response, the category reappears without the DELETE pending action — causing hasCustomCategories to return true again and the customizeCategories row to appear checked incorrectly.

This is a purely frontend issue: the completion state logic in the newly added TRACK_WORKSPACE branch of useGettingStartedItems does not survive the Onyx re-hydration that occurs after unrelated member operations.

[MelvinBot]

Proposal

What is the root cause of that problem?

When the user deletes a custom category, the DeleteWorkspaceCategories WRITE command sets pendingAction: DELETE optimistically and nullifies the category on success (Category.ts:1364-1372). However, when the user then navigates to the Workspace Members page, the OpenWorkspaceMembersPage READ command fires immediately (WorkspaceMembersPage.tsx:220). READ responses apply Onyx updates immediately (not queued behind WRITEs per OnyxUpdates.ts:35), so if the backend response includes POLICY_CATEGORIES data — either via onyxMethod: "set" (which replaces client state entirely) or including the category without pendingAction: DELETE — it re-introduces the deleted category into Onyx.

This makes hasCustomCategories() return true again, causing the "Customize accounting categories" task to appear checked at useGettingStartedItems.ts:92.

The bug was made visible by PR #88607 which added the TRACK_WORKSPACE intent to the Getting Started section — the underlying data race existed before but had no user-facing symptom.

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

The fix should ensure hasCustomCategories is resilient to stale backend data overwriting optimistic deletes. Two approaches:

1. Client-side (recommended): Track the "has user added a custom category" state as a separate persistent flag (e.g., in Onyx on the policy or a dedicated key) that gets set to true when the user creates a custom category via the Getting Started flow, rather than re-deriving it from the live policyCategories collection on every render. This makes the completion status immune to backend responses overwriting category data.

2. Backend-side (alternative): Ensure that READ commands like OpenWorkspaceMembersPage do not include POLICY_CATEGORIES in their response, or if they must, use onyxMethod: "merge" instead of "set" so they don't overwrite pending optimistic state.

What alternative solutions did you explore? (Optional)

• Adding a client-side "completed tasks" set that persists which Getting Started items have been completed, decoupling completion status from live data. This would also fix the related issue [$250] Onboarding- Task "Set up categories and tags" isn't auto-checked after completed #87482.
• Filtering hasCustomCategories to also exclude categories with stale pendingAction values — but this doesn't address the core problem of backend responses clearing pendingAction fields.

Supporting evidence

Key code locations:

• useGettingStartedItems.ts:88-106 — TRACK_WORKSPACE intent items including customizeCategories and inviteAccountant
• PolicyUtils.ts:717-725 — hasCustomCategories checks for non-default categories excluding pendingAction: DELETE
• Policy/Member.ts — Member add/remove actions do NOT touch POLICY_CATEGORIES in optimistic data, confirming the category change comes from backend responses
• OnyxUpdates.ts:35 — READ responses bypass the sequential queue and apply immediately

Possibly related: #87482 ("Set up categories and tags" isn't auto-checked after completed) — may share the same underlying cause of completion status being derived from live mutable data.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[ZhenjaHorbach]

Looks like BE issue
After removing a member, BE returns

{
    "key": "policyCategories_B407FC2D164B0374",
    "onyxMethod": "merge",
    "value": {
        "rules": {
            "approvalRules": []
        }
    }
}

BE is passing the value to the wrong Onyx Key
As a result, FE considers rules as a custom category
But the value { rules: { approvalRules: [] } } corresponds to the Policy.rules field — it doesn't belong in PolicyCategories, whose type is Record<string, PolicyCategory>
So in this case instead of "policyCategories_B407FC2D164B0374" it should be "policy_B407FC2D164B0374"