[Due for payment 2026-09-03] Workspace - Disabling a tag in a workspace with a very large tag list is unresponsive or takes over one minute to take effect, with no loading indicator

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number:
Reproducible in staging?: Needs Reproduction (Reproduction is blocked. Unable to check customer account)
Reproducible in production?: Needs Reproduction (Reproduction is blocked)
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @VictoriaExpensify
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Open the customer workspace
2. Go to Settings > Workspaces > customer workspace > Tags
3. Locate an enabled tag
4. Click the toggle to disable the tag
5. Observe that the toggle does not respond, or takes 1+ minutes to update, with no spinner or feedback

Expected Result:

The tag is disabled immediately, or within a few seconds, after clicking the toggle — with clear feedback that the change is processing.

Actual Result:

The toggle is either unresponsive or takes more than a minute before the tag is disabled. There is no loading indicator, so users re-click repeatedly, stacking multiple serialized requests. Backend requests actually complete in ~356–798ms and return 200 OK — the delay/freeze is client-side, driven by the workspace's ~1.1 MB tag list forcing heavy synchronous recomputation of tag violations/auto-selections on the JS thread on every click.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

For the customers' details check please OP

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081663553952814492
• Upwork Job ID: 2081663553952814492
• Last Price Increase: 2026-07-27

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

Problem

Toggling a single tag on the Workspace Tags page in a workspace with a very large (~1.1 MB) tag list freezes the JS thread for 1+ minute with no spinner. The backend responds in <1s / 200 OK — the delay is entirely client-side synchronous work that scales with the size of the whole tag list, not with the one tag being changed.

Root Cause

There are two compounding synchronous cost centers, both proportional to total tag count (and transaction/report count), that run on every toggle click:

1. Inside the action, before the API call. setWorkspaceTagEnabled builds a cheap single-tag optimistic write, but then unconditionally calls pushTransactionAutoSelectionsOnyxData and pushTransactionViolationsOnyxData. Each invokes getOptimisticPolicyState which shallow-clones the entire tag list (done twice per toggle), and the violations path then loops every transaction on every non-invoice report for the policy, each recompute re-scanning all tags via hasEnabledTags → effectively O(reports × transactions × tags), synchronously, before API.write even fires.

2. On the re-render after the Onyx emission. The optimistic write merges into the collection key holding the whole ~1.1 MB list, so Onyx re-emits the full list to subscribers. The Workspace Tags page then rebuilds a row object for every tag, and the generic Table re-runs its entire filter→search→sort→selection→highlight pipeline unmemoized in the render body (Table.tsx:206-234) — including a full O(n log n) localeCompare sort over all rows. This repeats on both the optimistic and success emissions.

There is also no per-toggle loading indicator — the Switch only has a disabled prop, and the page's ActivityIndicator only shows on initial load. So users get no feedback and re-click, stacking serialized requests.

Recommended Changes

1. Give the toggle immediate feedback so users stop re-clicking — a per-row pending state on the Switch driven by the optimistic write (pendingAction/pendingFields), instead of relying only on disabled.
2. Avoid the full-list recompute for a single-tag enable/disable. In setWorkspaceTagEnabled, scope getOptimisticPolicyState / auto-selection / violation recompute to only the affected tag(s) and affected transactions rather than cloning and re-deriving the whole policy state twice per click.
3. Memoize the Table middleware pipeline in Table.tsx so the localeCompare sort and other passes don't re-run on every render, and confirm tagRows only rebuilds when the visible tags actually change.

Related Issues

• Expensify/App#93952 (closed 2026-07-02) — "The Tags page does not open in NewDot, likely due to the large number of tags" — same large-tag-list performance class; the fix here should be consistent with whatever was done there.
• Expensify/App#90707 (closed) — "Bulk expense edit hangs and crashes on large reports" — same pattern of unbounded synchronous recompute at scale.

Investigation details & confidence

Confidence: High. Two independent code traces converged on the same client-side root cause; the backend timing in the report rules out a server bottleneck.

Data flow: Switch.onToggle → handleTagEnabledToggle → updateWorkspaceTagEnabled → setWorkspaceTagEnabled(policyData, {[tagName]: {...}}, 0) → pushTransactionAutoSelectionsOnyxData + pushTransactionViolationsOnyxData (each getOptimisticPolicyState full clone + per-transaction violation recompute) → Onyx.merge on POLICY_TAGS[policyID] → full-list re-emission → WorkspaceTagsPage tagRows rebuild + unmemoized Table sort/filter → repeats on success emission → only then is the UI free.

Key files: src/libs/actions/Policy/Tag.ts, src/libs/ReportUtils.ts (getOptimisticPolicyState, pushTransactionViolationsOnyxData), src/libs/Violations/ViolationsUtils.ts, src/pages/workspace/tags/WorkspaceTagsPage.tsx, src/components/Table/Table.tsx, src/components/Table/middlewares/sorting.ts.

Open item to confirm magnitude: the exact tag count and transaction/report count for the affected workspace, and whether the list is single- vs multi-level. A JS-thread CPU profile (React DevTools / Hermes) while toggling would pinpoint the dominant frame (expected: the violation loop and/or the Table localeCompare sort). This does not change the root cause, only quantifies the multiplier.

---

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

[j3ffffff]

Proposal

What is the root cause of that problem?

When the user toggles a single tag's enabled state, setWorkspaceTagEnabled in src/libs/actions/Policy/Tag.ts (line 257) calls two helpers before the Onyx optimistic write fires:

1. pushTransactionAutoSelectionsOnyxData (line 347)
2. pushTransactionViolationsOnyxData (line 358)

Both helpers call getOptimisticPolicyState in src/libs/ReportUtils.ts (line 2069). Inside that function, at lines 2114–2126, building optimisticTagLists requires a full clone of every tag in the list:

Object.fromEntries(Object.entries(tags).filter(...))   // iterates ALL ~N tags

With a ~1.1 MB tag list (potentially tens of thousands of tag entries) this is a heavy O(N) operation that runs synchronously on the main JS thread — and it runs twice (once per helper). Because all of this must complete before Onyx applies any optimistic state, the toggle shows no visual response until the clone is done. Backend requests return in ~400–800 ms fine, so the delay is entirely client-side.

The pendingAction fields that would show a loading spinner are only applied to Onyx after all this synchronous work finishes, so users see no feedback, assume the click was missed, and click again — stacking serialised requests.

Key files/lines:

• src/libs/actions/Policy/Tag.ts:347–369 — the two blocking helper calls in setWorkspaceTagEnabled
• src/libs/ReportUtils.ts:2114–2126 — the O(N) tag clone inside getOptimisticPolicyState
• src/libs/ReportUtils.ts:2303–2338 — the per-transaction violation loop that depends on the cloned tag list

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

Primary fix — avoid full tag-list cloning in getOptimisticPolicyState:

Instead of Object.fromEntries(Object.entries(tags).filter(...)) (which copies all N tags), use a constant-time merge strategy when only a small delta is provided. Because a single-tag enable/disable never deletes entries from the list (the filter always keeps everything), we can replace the clone with a shallow object spread of just the changed tags over the original reference:

// pseudo-code
optimisticTags = { ...tags, ...mergedTagUpdates }

Even better: use a lazy-evaluation approach (e.g. a Proxy or a helper function getOptimisticTag(tagName)) so that getViolationsOnyxData can resolve the tag state without materialising the full copy at all. This makes the work O(1) regardless of list size.

Secondary fix — apply the pending state before the heavy computation:

Split the Onyx write into two steps: first apply the optimistic pendingAction/pendingFields for the toggled tag immediately (so the spinner appears), then compute and apply the violation/auto-selection updates. The user sees instant feedback, and the heavier recomputation happens in the background.

Tertiary fix — guard the violation recompute for small deltas:

If the tag list has more than a threshold number of entries (e.g. 1 000), skip the client-side pre-computation of violations and auto-selections entirely and let the server response trigger the Onyx update. This is acceptable because the backend already recomputes and returns the correct violations within ~400 ms.

What alternative solutions did you explore? (Optional)

• Moving violation recomputation to a setTimeout/microtask to unblock the render — this would let the spinner appear, but doesn't fix the fundamental O(N) clone cost; the JS thread still freezes after one frame.
• Throttling/debouncing the toggle — avoids stacking requests but doesn't improve responsiveness.
• Memoising optimisticTagLists in getOptimisticPolicyState — possible, but tricky to invalidate correctly; the lazy-evaluation approach is cleaner.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Ollyws (External)

[melvin-bot]

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

[Ollyws]

@MelvinBot what would this code look like?

[MelvinBot]

Here's what each of the three recommended changes would look like in code. All line references are against 1688405.

The three changes are independent and land in order of impact: #1 is the cheap win that stops the re-click pile-up, #2 removes the actual per-toggle CPU cost, #3 stops the re-render from being O(n log n).

---

1. Immediate feedback on the toggled row

The optimistic write already stamps pendingAction: UPDATE / pendingFields.enabled: UPDATE on the tag (Tag.ts:271-275), so no new state is needed — just surface it. Add a pending prop to Switch that renders a spinner in place of the knob:

// src/components/Switch.tsx
type SwitchProps = {
    // ...existing props...
    /** Whether the switch is mid-flight (optimistic update pending) */
    pending?: boolean;
};

// in render, when `pending` is true render an ActivityIndicator instead of the animated knob,
// and treat the switch as non-interactive (guard handleSwitchPress on `disabled || pending`).

Then drive it from the row, off the tag's own pending state (WorkspaceTagsTableRow.tsx:149-159):

<Switch
    isOn={switchValue}
    showLockIcon={item.isLocked}
    disabled={isSwitchControlDisabled}
    pending={item.pendingFields?.enabled === CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE}
    accessibilityLabel={`${switchAccessibilityLabel}: ${item.name}`}
    onToggle={handleSwitchToggle}
/>

(pendingFields/pendingAction need to be carried onto the row object where tagRows is built in WorkspaceTagsPage.tsx if they aren't already.) This alone stops users from stacking serialized requests — but the JS thread is still frozen until #2 lands, so the spinner won't paint until then. They're complementary.

---

2. Don't recompute the whole policy for a single-tag toggle (the real fix)

Two cost centers run synchronously on every toggle, both scaling with the whole list, not the one changed tag:

• getOptimisticPolicyState rebuilds the full tag map via Object.fromEntries(Object.entries(tags).filter(...)) — twice per toggle (once from pushTransactionAutoSelectionsOnyxData, once from pushTransactionViolationsOnyxData).
• pushTransactionViolationsOnyxData then loops every transaction on every non-invoice report and calls getViolationsOnyxData, which re-scans all tags. That's O(reports × transactions × tags).

The clone is cheap to fix — since an enable/disable never removes keys, the Object.fromEntries(...filter...) can collapse to a shallow spread:

// src/libs/ReportUtils.ts — getOptimisticPolicyState, replacing L2114-2126
tags: {...tags, ...Object.fromEntries(
    Object.entries(tagsUpdate)
        .filter(([, tagUpdate]) => !!tagUpdate)
        .map(([tagName, tagUpdate]) => [tagName, {...(tags[tagName] ?? {}), ...tagUpdate}]),
)},

But the dominant cost is the transaction loop. A pure enable/disable of tag T can only change the tagOutOfPolicy/missingTag state of transactions currently tagged T (plus the single auto-select target). So scope the loop to affected transactions instead of all of them:

// src/libs/ReportUtils.ts — pushTransactionViolationsOnyxData
// Build the set of tag names touched by this update (single-level only).
const affectedTagNames = new Set(
    Object.values(tagListsUpdate).flatMap((tagList) => Object.keys(tagList?.tags ?? {})),
);
const isPureTagToggle = isPolicyUpdateEmpty && isCategoriesUpdateEmpty && affectedTagNames.size > 0;

for (const {transactionsAndViolations: {transactions, violations}} of nonInvoiceReportItems) {
    for (const transaction of Object.values(transactions)) {
        // Fast path: a tag enable/disable only affects transactions that use the changed tag
        // (or one that was just auto-selected). Everything else keeps its current violations.
        if (isPureTagToggle && !transactionAutoSelections.has(transaction.transactionID) && !(transaction.tag && affectedTagNames.has(transaction.tag))) {
            continue;
        }
        // ...existing getViolationsOnyxData recompute...
    }
}

That takes the per-toggle work from O(reports × transactions × tags) down to roughly O(affected transactions).

Correctness notes / things to confirm before implementing

• Single- vs multi-level tags. transaction.tag is a colon-joined string for multi-level lists, so affectedTagNames.has(transaction.tag) only matches cleanly for single-level. This mirrors the existing single-level-only guard in pushTransactionAutoSelectionsOnyxData (ReportUtils.ts:2198) — for multi-level lists the fast path should be skipped (fall back to the current full loop) rather than risk missing a transaction.
• Dependent tags (hasDependentTagsValue) — a toggle there can affect combinations, so the pure-toggle fast path should also bail when hasDependentTags is true.
• j3ffffff's proposal above proposes a size-threshold guard as an alternative (skip client recompute entirely above N tags and let the server response drive it). That's simpler but changes behavior — it drops optimistic violations for large lists. Scoping by affected tag keeps optimism intact, so I'd lean toward this.

---

3. Memoize the Table pipeline

The filter→search→sort→selection→highlight passes run unmemoized in the render body (Table.tsx:206-234), so the full localeCompare sort (sorting.ts) re-runs on every emission — both the optimistic write and the success write. Wrap each stage so it only recomputes when its own inputs change:

// src/components/Table/Table.tsx
const filteredData = useMemo(() => filterMiddleware(data), [filterMiddleware, data]);
const searchedData = useMemo(() => searchMiddleware(filteredData), [searchMiddleware, filteredData]);
const sortedData = useMemo(() => sortMiddleware(searchedData), [sortMiddleware, searchedData]);      // the O(n log n) localeCompare
const selectionData = useMemo(() => selectionMiddleware(sortedData), [selectionMiddleware, sortedData]);
const processedData = useMemo(() => highlightMiddleware(selectionData), [highlightMiddleware, processedData]);

For this to actually help, the *Middleware callbacks returned by the useFiltering/useSearching/useSorting/… hooks must be stable (memoized on their config), and tagRows in WorkspaceTagsPage.tsx (L343-435) must be a useMemo keyed on the visible tags — otherwise a fresh data array identity every emission defeats the memo. Note the React Compiler may already auto-memoize parts of this; worth checking the compiled output before adding manual useMemos so you don't fight it.

---

Happy to open a draft PR for any/all of these — reply @MelvinBot implement [this](https://github.com/Expensify/App/issues/97070) and I'll start with #1 + #2 since together they fix the freeze.

[melvin-bot]

@Ollyws Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[Ollyws]

@MelvinBot implement this