[Due for payment 2026-09-17] Workspace - Enabled features are not highlighted

[applause-bot]

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

---

Version Number: 9.4.75-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #99665
Email or phone of affected tester (no customers): gocemate+asdf@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iphone 11/26.2
App Component: Workspace Settings

Action Performed:

Precondition: login with a new Gmail account

1. Create workspace
2. Tap on More options
3. Enable any feature

Expected Result:

Enabled feature should appear highlighted

Actual Result:

Enabled feature does not appear highlighted

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7255603_1788996926471.ScreenRecording_09-10-2026_01-28-47_1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @abzokhattab

[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/3613ba1f2fa1a912fc4d643418c1ad559980fba0804808a11b2a33b12177e3aa

[melvin-bot]

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

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

[melvin-bot]

@chuckdries @ZhenjaHorbach you have been assigned to this deploy blocker because you reviewed the offending PR: #99665

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98744 - "refactor: the new-transaction highlight rail and the wide RHP width model" by @TaduJR (High confidence)
Related Issues: None found

⚠️ The auto-assigned PR #99665 ("Fix infinite amount and pending rate when submitting a self DM distance expense quickly") is refuted. That PR only touches src/components/MoneyRequestConfirmationList/hooks/useDistanceRequestState.ts, src/components/ReportActionItem/MoneyRequestView.tsx, src/hooks/useParticipantSubmission.ts and src/libs/TransactionUtils/*. It does not touch the More features page, ToggleSettingsOptionRow, the workspace menu, or any highlight/animation code. The PR link in the bug report came from the Applause "regression testing" field, not from an actual code match.

Recommendation: ROLL FORWARD

The regression is a few lines inside useAnimatedHighlightStyle, whereas #98744 is a ~50 file cross-cutting refactor (wide-RHP width model, ReportMetadata Onyx type, PendingNewTransactionFlags, IOU actions/selectors) that landed a day ago, so a revert is far riskier than the targeted fix and would reintroduce the highlight bugs it fixed. The fix is to make an already-armed highlight play its pulse even after the transient shouldHighlight flag is retracted (and to not clear an awaitingFocus play when it is retracted).

Assigned: @TaduJR (PR author), @abzokhattab and @blimpich (approving reviewers) from highest-confidence causing PR only
Labels: No changes. DeployBlockerCash is kept (App-side regression, App deploy is blocked). DeployBlocker was not present, so nothing removed.

📋 Detailed Analysis

Evidence

• Reproducible on staging (9.4.75-0) only, not production — so the cause is a PR in Deploy Checklist #100739.
• The "highlight" in this flow is the workspace menu row that appears after a feature is enabled. WorkspaceInitialPage renders each row through HighlightableMenuItem, which delegates to useAnimatedHighlightStyle.
• I compared every file on the highlight path between production and staging:
  • src/pages/workspace/WorkspaceMoreFeaturesPage/MoreFeatureToggle.tsx — byte-identical.
  • src/pages/workspace/WorkspaceMoreFeaturesPage/MoreFeaturesSection.tsx, index.tsx — unchanged in this release.
  • src/pages/workspace/workflows/ToggleSettingsOptionRow.tsx — only a whitespace/comment change from #100576 (isActive, wrapperStyle, Switch wiring untouched).
  • src/components/HighlightableMenuItem.tsx — only a doc-comment removal from [No QA] Remove comments that do not add context #100576.
  • src/pages/workspace/getWorkspaceMenuItems.ts — only comment removal; the highlight trigger on L180 is functionally identical to production.
  • src/hooks/useAnimatedHighlightStyle/index.ts — rewritten by refactor: the new-transaction highlight rail and the wide RHP width model #98744. This is the only functional change on the path.

Verification

• Affected files:
  • src/hooks/useAnimatedHighlightStyle/index.ts (changed by refactor: the new-transaction highlight rail and the wide RHP width model #98744)
  • src/pages/workspace/getWorkspaceMenuItems.ts#L180 (produces the transient highlighted flag — unchanged)
  • src/components/HighlightableMenuItem.tsx (consumer — unchanged)
• Confirmed refactor: the new-transaction highlight rail and the wide RHP width model #98744 modifies src/hooks/useAnimatedHighlightStyle/index.ts and src/hooks/useScreenWrapperTransitionStatus.ts (gh api repos/Expensify/App/pulls/98744/files), merged 2026-09-09T00:07:42Z, i.e. immediately before the 9.4.75-0 staging build where the bug first appeared.
• Confirmed the file blob on staging (bf97c6cc…) matches the version at refactor: the new-transaction highlight rail and the wide RHP width model #98744's merge commit 3aaa7f70, so the line references above are the shipped code.

Root Cause

getWorkspaceMenuItems sets highlighted as a one-shot, transient flag:

const highlightedPolicyFeature = getObjectKeys(policyFeatureStates)
    .find((key) => policyFeatureStates[key] && !previousPendingFields?.[key] && policy?.pendingFields?.[key]);

previousPendingFields comes from usePrevious(policy?.pendingFields), so highlighted is true only for the render(s) immediately after the optimistic toggle and flips back to false on the very next re-render — long before the ~350 ms entry animation (ANIMATED_HIGHLIGHT_ENTRY_DELAY 50 + ANIMATED_HIGHLIGHT_ENTRY_DURATION 300) completes.

Before #98744, the colour pulse was scheduled unconditionally from the entry-animation completion callback, so a transient flag still produced a visible highlight.

#98744 added two new gates that both drop the pulse for a transient flag:

1. L120-L126 — the completion callback now re-reads the current flag:

   const pulseIfStillHighlighted = () => {
       if (!prevShouldHighlightRef.current) {
           return;
       }
       playPulse();
   };

   By the time the entry finishes, prevShouldHighlightRef.current is already false, so playPulse() never runs. This is the wide-layout (Windows Chrome) failure.

2. L143-L167 — on narrow layouts (shouldUseNarrowLayoutOnWideRHP === true, i.e. Android/iOS App) the row is only revealed and the pulse is deferred to the next focus event with playPhaseRef.current = 'awaitingFocus'. But the retraction branch at L100-L107 resets playPhaseRef.current to 'idle' as soon as shouldHighlight goes false, so when the user navigates back the listener bails on if (playPhaseRef.current !== 'awaitingFocus') { return; }. This is the deterministic mobile failure and matches the reported Android/iOS platforms.

Net effect: the newly enabled feature's row still fades in, but the green highlight pulse never plays — exactly "Enabled feature does not appear highlighted".

Suggested fix direction (keeping #98744's FlashList-recycling protection intact): latch the arming decision per row instance instead of re-reading the live flag — e.g. keep a didArmForThisRow ref set when the play is armed and cleared only when the row identity changes, gate pulseIfStillHighlighted and the focus listener on that latch rather than on prevShouldHighlightRef.current / a playPhase that a retraction clears.