[Due for payment 2026-04-28] [$250] Android & iOS - Chronos - Start timer dropdown button is broken

[lanitochka17]

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.3.59.1
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #87543
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: User Settings

Action Performed:

1. Go to staging.new.expensify.com
2. Open chat with chronos@expensify.com

Expected Result:

Start timer dropdown button will appear without issue.

Actual Result:

Start timer dropdown button is broken.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022043842308834756692
• Upwork Job ID: 2043842308834756692
• Last Price Increase: 2026-04-14

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

Triggered auto assignment to @srikarparsi (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

What is the root cause of that problem?

getCustomUnitsForDuplication in PolicyUtils.ts:312-352 copies the source workspace's custom unit objects verbatim under new record keys, but never updates the internal customUnitID field. This creates a mismatch: the Onyx record key is the new ID, but customUnit.customUnitID still holds the old source workspace's ID.

When the user adds a distance rate, CreateDistanceRatePage.tsx:43-44 reads customUnit.customUnitID (the stale old ID) and passes it to createPolicyDistanceRate. The server rejects this because the duplicated workspace's custom unit was created with the new ID.

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

In getCustomUnitsForDuplication (PolicyUtils.ts), spread the unit object and override customUnitID with the new ID on all three return paths:

• Line 336: {[distanceCustomUnitID]: {...distanceCustomUnit, customUnitID: distanceCustomUnitID}, [perDiemCustomUnitID]: {...perDiemUnit, customUnitID: perDiemCustomUnitID}}
• Line 344: {[distanceCustomUnitID]: {...distanceCustomUnit, customUnitID: distanceCustomUnitID}}
• Line 351: {[perDiemCustomUnitID]: {...perDiemUnit, customUnitID: perDiemCustomUnitID}}

The existing unit test at PolicyUtilsTest.ts:338 should also be updated to pass genuinely different IDs (instead of reusing the source unit's ID) so the mismatch is caught in tests.

Investigation details

Data flow:

1. buildDuplicatePolicyData calls buildOptimisticDistanceRateCustomUnits generating a new distanceCustomUnitID (UUID)
2. getCustomUnitsForDuplication finds the source unit by name and returns {[newID]: originalUnitObject} where originalUnitObject.customUnitID is the old ID
3. Onyx stores policy.customUnits = {[newID]: {customUnitID: oldID, ...}}
4. Server receives distanceCustomUnitID: newID in the DuplicatePolicy params and creates the unit with that new ID
5. CreateDistanceRatePage calls getDistanceRateCustomUnit(policy) which returns the object with customUnitID: oldID
6. createPolicyDistanceRate(policyID, oldID, newRate) fails because oldID doesn't exist on the server for the new workspace

Same bug affects perDiem rates on duplicated workspaces (same code paths, lines 336 and 347-351).

Possibly related: #86116 ("In duplicate workspace, creating distance manual expense shows unexpected error") likely shares the same root cause.

---

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.

[OSBotify]

Investigation Summary

Classification: Needs more context - potentially Frontend bug or pre-existing issue
Causing PR: No single high-confidence causing PR identified
Related Issues: None identified

Recommendation: NEEDS INVESTIGATION

Cannot identify the root-cause PR with sufficient confidence. The bug is staging-only and is likely a pre-existing issue in the workspace duplication and distance rates flow, rather than a regression from a specific PR in this staging build.

Labels: No changes made - keeping DeployBlockerCash until root cause is confirmed

Detailed Analysis

Bug scenario: New user logs in via track and budget expense onboarding, duplicates the created workspace, opens the duplicate workspace, navigates to Distance Rates, tries to add a rate, and fails.

Version: V9.3.58-3 (staging only, not reproducible in production).

Likely root cause (pre-existing):

When a workspace is duplicated, buildDuplicatePolicyData in src/libs/actions/Policy/Policy.ts sets custom units via getCustomUnitsForDuplication. For a brand-new onboarding user, the workspace is created with areDistanceRatesEnabled: false. The Distance Rates feature option does NOT appear in WorkspaceDuplicateSelectFeaturesForm because it only shows when ratesCount > 0 AND policy?.areDistanceRatesEnabled (line 150 of WorkspaceDuplicateSelectFeaturesForm.tsx).

Therefore isDistanceRatesOptionSelected is false, and customUnits is undefined in the duplicated workspace optimistic data. If the user then manually enables Distance Rates via More Features on the duplicate workspace, getDistanceRateCustomUnit(policy) still returns undefined because no distance custom unit was ever copied.

When the user navigates to CreateDistanceRatePage, line 50 checks:
const FullPageBlockingView = !customUnitID ? FullPageOfflineBlockingView : View

With customUnitID undefined, the offline blocking view is shown, preventing the user from adding a rate.

Relevant files:

• src/pages/workspace/distanceRates/CreateDistanceRatePage.tsx - FullPageOfflineBlockingView guard at line 50
• src/pages/workspace/duplicate/WorkspaceDuplicateSelectFeaturesForm.tsx - distanceRates option only shows if ratesCount > 0 AND policy?.areDistanceRatesEnabled (line 150)
• src/libs/PolicyUtils.ts - getCustomUnitsForDuplication at line 312 returns undefined when distance rates not selected

PRs checked from staging that are NOT the cause:

PR 87334 (Refactor ConfirmModal usage in workspace settings pages part 3) - only changes delete/warning modals in PolicyDistanceRatesPage.tsx, not the add-rate flow.

PR 87694 (Split accounting and HR connection groups) - modifies WorkspaceDuplicateSelectFeaturesForm.tsx but only for accounting connection filtering, does not affect distance rate custom unit creation.

Why staging-only: The test used a brand-new account with track and budget expense onboarding - an edge case discovered through exploratory QA.

Next steps:

1. Confirm whether Distance Rates was enabled via More Features AFTER duplicating, or was selected during the duplication features form
2. Verify if the issue reproduces when the source workspace has areDistanceRatesEnabled: true with existing rates
3. If confirmed pre-existing: fix enablePolicyDistanceRates in src/libs/actions/Policy/DistanceRate.ts to also create a default customUnit when enabling Distance Rates on a workspace that lacks one