[Due for payment 2026-05-22] [Due for payment 2026-05-20] Distance - RHP does not animate after changing distance rate

[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.73-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: #90358
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Enable Distance rates in workspace settings.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Distance rates.
3. Click Settings.
4. Click Unit.
5. Select another rate.

Expected Result:

RHP will animate after changing distance rate.

Actual Result:

RHP does not animate after changing distance rate.

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

Issue Owner

Current Issue Owner: @abzokhattab

[melvin-bot]

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

[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: #90358 - "Refactor ReanimatedModal/index.tsx to follow Rules of React and compile with React Compiler" by @roryabraham (High confidence)
Related Issues: #68765

Recommendation: REVERT

PR #90358 refactored the modal animation state management in a way that broke RHP animations when navigating between screens within the panel. Reverting this PR is the cleanest path to restoring correct behavior since the change is an isolated refactor of a single file.

Assigned: @roryabraham (PR author), @abzokhattab (approving reviewer), @carlosmiceli (approving reviewer)
Labels: DeployBlockerCash kept (Frontend bug in App PR). No label changes made.

Detailed Analysis

Evidence

• The issue title references PR [Payment due @abzokhattab] Refactor ReanimatedModal/index.tsx to follow Rules of React and compile with React Compiler #90358 directly in the regression test field, and melvin-bot confirmed this assignment.
• PR [Payment due @abzokhattab] Refactor ReanimatedModal/index.tsx to follow Rules of React and compile with React Compiler #90358 was merged on 2026-05-13T00:08:25Z and is listed in the StagingDeployCash for version 9.3.73-0.
• The bug is staging-only and not reproducible in production, consistent with a newly merged staging PR being the cause.
• The affected behavior (RHP not animating when changing the distance rate unit) is precisely a modal animation regression — exactly what this PR touched.

Verification

• The only file changed in PR [Payment due @abzokhattab] Refactor ReanimatedModal/index.tsx to follow Rules of React and compile with React Compiler #90358 is src/components/Modal/ReanimatedModal/index.tsx.
• The reported bug is that the RHP (Right Hand Panel, which uses MODAL_TYPE.RIGHT_DOCKED / ReanimatedModal) does not animate when the user selects a new unit on the Distance Rates settings page.
• This directly implicates ReanimatedModal/index.tsx and the Container web component that drives the entry/exit animations.

Root Cause

The old code maintained an isVisibleState state variable that mirrored the isVisible prop with a one-render delay. The containerView was rendered conditionally on isVisibleState (not isVisible directly). This one-render lag meant that when navigating between RHP screens — where React Navigation briefly sets isVisible to false for the outgoing screen before the new screen appears — the containerView stayed mounted during that momentary false window, allowing the Container's entry/exit Keyframe animations to run smoothly.

PR #90358 removed isVisibleState entirely and replaced {isVisibleState && containerView} with {isVisible && containerView} (lines 228 and 237 of the refactored file). Now, when isVisible briefly transitions false -> true during RHP navigation, the Container unmounts immediately and remounts, disrupting the animation sequence. The Container's Exiting Keyframe animation fires on unmount (calling onCloseCallBack, setting isContainerOpen = false), then the Container remounts and attempts an entering animation — but the rapid mount/unmount cycle produces a broken or missing animation on web (Chrome/Safari), matching the reported symptom.

The derived isTransitioning = isVisible !== isContainerOpen logic does keep modalVisibility (and thus the outer Modal) visible during this window, but the inner containerView is gated on isVisible directly, so it still unmounts/remounts and loses the smooth animation.