[Due for payment 2026-07-17] [$250] Distance expense - Unexpected error when creating distance expense in DM after clearing cache

[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: 9.3.60-17
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177029/test-cases/68907543
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 15.7.4 Chrome
App Component: Money Requests

Action Performed:

1. Sign in to ND as a new user
2. Create a 1:1 chat with another existing user, send a message
3. Navigate to the Account -Troubleshoot - click "Clear cache and restart" - "Reset and refresh"
4. Open the chat from step 2, click "+" button - Track distance - Map
5. Enter two waypoints - Next - Create expense
6. Wait for the map to be created and observe the expense preview, open the details

Expected Result:

Distance expense is created successfully in 1:1 chat after clearing cache

Actual Result:

User is not able to create a distance expense in 1:1 chat after clearing cache, unexpected errors occur

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7132504_1776452777153.Distance_expense_after_clearing_cache.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054391368956022692
• Upwork Job ID: 2054391368956022692
• Last Price Increase: 2026-05-27

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

After clearing cache, Onyx.clear() wipes all policy data and reports (they're not in KEYS_TO_PRESERVE). The data is then refetched asynchronously via openApp(). This creates a race condition in initMoneyRequest:

if (!isFromGlobalCreate) {
    comment.customUnit = {customUnitRateID, name: DISTANCE};
} else if (hasOnlyPersonalPolicies) {
    comment.customUnit = {customUnitRateID: FAKE_P2P_ID, name: DISTANCE};
}
// ELSE: customUnit is NEVER set

isFromGlobalCreate is derived from !report?.reportID. After cache clear, the report may still be loading from the server when the distance flow initializes, making this true even though the user started from a chat.

hasOnlyPersonalPolicies defaults to true when policies haven't loaded, but if the OpenApp response delivers workspace policies before the report finishes loading, it becomes false.

When both conditions align (isFromGlobalCreate=true + hasOnlyPersonalPolicies=false), customUnit is never set on the transaction draft. The expense is then submitted without proper distance rate configuration, causing the backend to reject it with the generic "Unexpected error submitting this expense" message.

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

Add an else branch in initMoneyRequest so that customUnit is always set for distance requests, even when isFromGlobalCreate=true && hasOnlyPersonalPolicies=false:

if (!isFromGlobalCreate) {
    const customUnitRateID = DistanceRequestUtils.getCustomUnitRateID({...});
    comment.customUnit = {customUnitRateID, name: DISTANCE};
} else if (hasOnlyPersonalPolicies) {
    comment.customUnit = {customUnitRateID: FAKE_P2P_ID, name: DISTANCE};
} else {
    // Fallback: set FAKE_P2P_ID so the transaction draft always has a customUnit for distance requests.
    // The correct rate will be resolved later when the user selects a workspace on the participants page.
    comment.customUnit = {customUnitRateID: FAKE_P2P_ID, name: DISTANCE};
}

This ensures distance expenses always have a customUnit regardless of the load order of policies vs reports after cache clear.

What alternative solutions did you explore?

An alternative would be to block the expense creation UI until all data from openApp() is fully loaded (e.g., showing a loading spinner). However, this would degrade UX for all users, not just those who recently cleared cache. The fallback approach is more targeted and consistent with how the existing P2P path already handles missing policy data.

Investigation details

Data flow after cache clear:

1. clearOnyxAndResetApp() calls Onyx.clear() — wipes all policy/report data
2. openApp() is called in a promise chain to refetch data
3. User navigates to 1:1 DM and starts "Track distance" flow
4. useResetIOUType triggers initMoneyRequest — but report may not be loaded yet
5. customUnit is skipped due to the race condition
6. TRACK_EXPENSE API call sent without proper distance rate configuration → backend rejects

Key files:

• MoneyRequest.ts:899-905 — gap where customUnit is not set
• useResetIOUType.ts:87 — isFromGlobalCreate derived from report availability
• useResetIOUType.ts:103 — hasOnlyPersonalPolicies default
• App.ts:125-150 — KEYS_TO_PRESERVE list (policies/reports not included)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After clearing cache and restarting, creating a distance expense in a 1:1 DM produces an unexpected error when the expense preview renders with the map and the user opens the details. The map fails to initialize correctly and a TypeError bubbles out of mapbox-gl, leaving the preview in a broken state instead of showing the waypoints and the directions line between them.

What is the root cause of that problem?

On web, MapViewImpl.website.tsx mounts its Map children — the current-position Marker, the distance-label Marker, the waypoint Markers, and the Direction component (which adds a Source and Layer) — immediately on the first render, before the Mapbox map's style has finished loading. When the cache is warm, the style is available synchronously from the in-memory store and the initial render completes fast enough that the children attach to a fully initialized map. After a "Clear cache and restart", the style tiles and the style JSON must be refetched cold, so there is a window where the Map component exists but its internal transform is not yet initialized.

During that window, the child Source/Layer pair from Direction registers with the map and mapbox-gl runs its layer-placement path that evaluates fog opacity. On the uninitialized transform this throws Cannot read properties of undefined (reading 'get') from _queryFogOpacity. The exception propagates up through the render tree and surfaces as the "unexpected error" state on the transaction preview/details.

The children are rendered unconditionally here, with no gating on the map's load state:

App/src/components/MapView/MapViewImpl.website.tsx

Lines 259 to 312 in d3831cc

	<Map
	onDrag={() => setUserInteractedWithMap(true)}
	ref={setRef}
	mapLib={mapboxgl}
	mapboxAccessToken={accessToken}
	initialViewState={initialViewState}
	style={{...StyleUtils.getTextColorStyle(theme.mapAttributionText), zIndex: -1}}
	mapStyle={styleURL}
	interactive={interactive}
	>
	{interactive && (
	<Marker
	key="Current-position"
	longitude={currentPosition?.longitude ?? 0}
	latitude={currentPosition?.latitude ?? 0}
	>
	<View style={styles.currentPositionDot} />
	</Marker>
	)}
	{!!distanceSymbolCoordinate && !!distanceInMeters && !!distanceUnit && (
	<Marker
	key="distance-label"
	longitude={distanceSymbolCoordinate.at(0) ?? 0}
	latitude={distanceSymbolCoordinate.at(1) ?? 0}
	>
	<PressableWithoutFeedback
	sentryLabel="MapView-ToggleDistanceUnit"
	accessibilityLabel={CONST.ROLE.BUTTON}
	role={CONST.ROLE.BUTTON}
	onPress={toggleDistanceUnit}
	>
	<View style={styles.distanceLabelWrapper}>
	<Text style={styles.distanceLabelText}> {DistanceRequestUtils.getDistanceForDisplayLabel(distanceInMeters, distanceUnit)}</Text>
	</View>
	</PressableWithoutFeedback>
	</Marker>
	)}
	{waypoints?.map(({coordinate, markerComponent, id}) => {
	const MarkerComponent = markerComponent;
	if (utils.areSameCoordinate([coordinate[0], coordinate[1]], [currentPosition?.longitude ?? 0, currentPosition?.latitude ?? 0]) && interactive) {
	return null;
	}
	return (
	<Marker
	key={id}
	longitude={coordinate[0]}
	latitude={coordinate[1]}
	>
	<MarkerComponent />
	</Marker>
	);
	})}
	{!!directionCoordinates && <Direction coordinates={directionCoordinates} />}
	</Map>

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

Defer the map's child layers until Mapbox has actually finished loading the style, so nothing attaches to a half-initialized map.

Concretely, in MapViewImpl.website.tsx:

1. Introduce a local isMapLoaded boolean state, initialized to false.
2. Pass an onLoad handler to the Map component that flips isMapLoaded to true. react-map-gl emits this once the underlying mapbox-gl map has finished its initial style/transform setup.
3. Gate each of the map's children — the current-position Marker, the distance-label Marker, the waypoint Markers, and the Direction component — behind isMapLoaded, so they only render after the onLoad event has fired.

This removes the race completely: the Source/Layer pair from Direction and the Marker children only mount once the map's internal state is fully initialized, so the fog-opacity path in mapbox-gl always sees a valid transform and no exception is thrown. On warm caches the onLoad event fires almost immediately, so there is no observable regression; on cold caches (the cache-clear scenario) the children wait a few hundred extra milliseconds for the style to finish loading, which is strictly preferable to crashing the preview.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/88235-mapview-direction-onload-gate?expand=1

What alternative solutions did you explore? (Optional)

A narrower variant would gate only the Direction component, since its Source/Layer pair is the part that triggers the fog-opacity evaluation path inside mapbox-gl. That would preserve eager rendering of the Markers. However, Markers also resolve their pixel positions against the map's transform on first render, so under a cold cache they can hit the same uninitialized-transform state and cause related symptoms (misplaced pins, blank tiles). Gating all children uniformly behind isMapLoaded is a single, consistent rule that covers the whole class of races rather than patching the one path we happened to observe.

Another alternative would be to wrap the first render of the child layers in a try/catch so the exception is swallowed. That would keep the preview from entering the error state but would leave the children mounted against a broken map, which would likely surface as missing markers or a blank route line — trading one user-visible failure mode for another. Deferring the mount until onLoad fixes the underlying sequencing rather than masking the symptom.