[$250] [Metrics] ManualSubmitToDestinationVisible — SubmitExpenseOrchestrator + centralized telemetry (part 1)

[mountiny]

Context

This issue tracks part 1 of the ManualSubmitToDestinationVisible work (submit → destination visible telemetry and performance). It corresponds to the refactor delivered in PR #87963.

Goal

Prepare and instrument the submit-to-destination flow without changing intended product behavior: consolidate orchestration and telemetry so follow-up changes (dismiss-first fast paths) can land safely.

What shipped in #87963

• SubmitExpenseOrchestrator — Extracts the submit decision tree (including GPS permission handling and telemetry lifecycle) from IOURequestStepConfirmation into a dedicated render-prop component. Only the default slow path is active in this PR.
• Centralized telemetry in submitFollowUpAction.ts — Single place for tracking session management (startTracking, setFastPath, addOptimization, cancelTracking), follow-up action state, and structured __DEV__ logging (e.g. [SubmitExpense] request_money_manual -> navigate_to_search (none) 105ms [slow path]).
• isTracking() — Replaces scattered getSpan() checks in navigation helpers and IOU actions where appropriate.
• useEndSubmitNavigationSpans — Shared hook for span-ending logic previously duplicated in SearchPageNarrow and SearchPageWide.
• Bugfix — Clear trackingState when cancelSubmitFollowUpActionSpan runs so telemetry state stays consistent.

Out of scope (follow-up)

• Dismiss-first navigation fast paths and [fast path] labeling are intentionally deferred to PR #87768 (HOLD on [Performance] Refactor: Extract SubmitExpenseOrchestrator + centralize telemetry #87963).

Acceptance criteria

• All expense submit flows behave as before (including distance + GPS permission).
• Telemetry lifecycle is centralized; in dev, console shows structured [SubmitExpense] lines after submit.
• No regressions in navigation after expense creation (Search, Inbox report, RHP, modal dismiss paths).

Links

• Parent epic: [Due for payment 2026-04-23] [Due for Payment 2026-04-14][Metrics] ManualSubmitToDestinationVisible - Measure end-to-end time from expense creation submit to destination page render #83634
• Implementation PR: [Performance] Refactor: Extract SubmitExpenseOrchestrator + centralize telemetry #87963
• Follow-up PR: [Performance] Extend dismiss-first navigation fast paths + deferred writes #87768

Issue Owner

Current Issue Owner: @JakubKorytko

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044561206615367758
• Upwork Job ID: 2044561206615367758
• Last Price Increase: 2026-04-15

[MelvinBot]

Issue Analysis

Status: PR #87963 is open with all 32 CI checks passing. It has one approval from ShridharGoel and a pending review request from mountiny.

Root Cause (of any delay): This is a tracking issue for a planned refactor, not a bug. The implementation PR is code-complete and CI-green — it's awaiting final review.

PR #87963 Code Review Summary: The refactor is clean and behavior-preserving. No bugs found. Specifically:

• SubmitExpenseOrchestrator correctly extracts the submit decision tree (GPS permission flow, telemetry, confirm logic) from IOURequestStepConfirmation into a render-prop component
• Centralized telemetry (startTracking, isTracking, cancelTracking) replaces 4 scattered startSpan callsites and keeps span/state in sync
• useEndSubmitNavigationSpans deduplicates span-ending logic from SearchPageNarrow/SearchPageWide with a minor improvement: DISMISS_MODAL_ONLY skips the layout gate on narrow (page already mounted)
• Bugfix for stale trackingState on cancel is correct
• shouldHandleNavigation parameter threaded through all expense creation functions defaults to true, preserving current behavior

One minor note for follow-up

Between this PR merging and PR #87768, the pre-insert search route useEffect still fires on narrow layout but the fast path that would use it on confirm is removed. This is harmless — removePreInsertedFullscreenIfNeeded handles cleanup on unmount — but worth keeping in mind during Part 2 review.

Acceptance criteria assessment: All three criteria from the issue appear met by the PR:

1. Submit flows preserved (including distance + GPS permission) ✓
2. Telemetry lifecycle centralized with structured [SubmitExpense] dev logging ✓
3. No navigation regressions (all test jobs pass) ✓

---

Next Steps: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

Current assignee @ShridharGoel is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[yuvrajangadsingh]

Proposal

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

Submit-to-destination telemetry is scattered across multiple files. IOURequestStepConfirmation owns the submit decision tree, GPS permission flow, and telemetry span lifecycle all in one 1500+ line component. Span checks (getSpan()) are duplicated in navigation helpers and search pages. This scatter makes it fragile to add fast-path optimizations and leaves a bug where trackingState isn't cleared on cancel.

What is the root cause of that problem?

Three things are tangled together in IOURequestStepConfirmation.tsx:

1. Telemetry span management is inline. startSpan(SPAN_SUBMIT_EXPENSE) at line 1057, then markSubmitExpenseEnd() called 17 separate times across every branch of createTransaction (lines 1074, 1121, 1157, 1191, 1213, 1226, 1236, 1242, 1250, 1254, 1260, 1278, 1288, 1294, 1302, 1307). Each branch must remember to close the span or it leaks.

2. Span existence checks are scattered. dismissModalAndOpenReportInInboxTab.ts checks getSpan(SPAN_SUBMIT_TO_DESTINATION_VISIBLE) to decide whether to set follow-up actions. Split.ts does the same at line 2292. These should use a single isTracking() API rather than reaching into raw span state.

3. Span-ending logic is duplicated. SearchPageNarrow (lines 188-212) and SearchPageWide (lines 64-73) both implement their own callback for ending submit navigation spans, with slightly different gating logic (narrow needs focus+layout dual-gate, wide doesn't).

4. Bug: cancelSubmitFollowUpActionSpan() in submitFollowUpAction.ts cancels the Sentry span and clears pendingSubmitFollowUpAction, but doesn't clear trackingState. If a user cancels mid-flow and starts a new submit, stale tracking state pollutes the next session's telemetry.

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

Affected surfaces: 12 source files + 5 test files.

New files (2):

1. src/pages/iou/request/step/confirmation/SubmitExpenseOrchestrator.tsx - Render-prop component that extracts submit orchestration from IOURequestStepConfirmation. Owns isConfirming, selectedParticipantList, and startLocationPermissionFlow state. Calls startTracking() + setFastPath(DEFAULT) before createTransaction(). Renders LocationPermissionModal conditionally. Only the default (slow) path is active; fast-path handlers are deferred to PR [Performance] Extend dismiss-first navigation fast paths + deferred writes #87768.

2. src/hooks/useEndSubmitNavigationSpans.ts - Shared hook replacing duplicated span-ending logic. Takes {requireLayout: boolean}. Narrow layout (requireLayout: true) dual-gates on focus+layout signals, with a carve-out for DISMISS_MODAL_ONLY where focus alone suffices (page already mounted). Wide layout (requireLayout: false) ends immediately on any signal.

Modified files (10):

3. src/libs/telemetry/submitFollowUpAction.ts - Add TrackingState module-level state, startTracking() (replaces scattered startSpan calls, starts both SPAN_SUBMIT_EXPENSE and SPAN_SUBMIT_TO_DESTINATION_VISIBLE), setFastPath() (write-once per session), addOptimization(), cancelTracking(), isTracking(). In endSubmitFollowUpActionSpan, emit structured __DEV__ log like [SubmitExpense] request_money_manual -> navigate_to_search (none) 105ms [slow path]. Bugfix: set trackingState = null inside cancelSubmitFollowUpActionSpan.

4. src/CONST/index.ts - Add ATTRIBUTE_FAST_PATH_HANDLER, FAST_PATH_HANDLER enum (search_pre_insert, report_pre_insert, dismiss_modal, etc.), SUBMIT_OPTIMIZATION enum (pre_insert, dismiss_first, deferred_write).

5. src/pages/iou/request/step/IOURequestStepConfirmation.tsx - Remove startLocationPermissionFlow, selectedParticipantList, isConfirming state, startSubmitSpans(), onConfirm(), and LocationPermissionModal JSX. Wrap MoneyRequestConfirmationList in SubmitExpenseOrchestrator render prop. Thread shouldHandleNavigation parameter through requestMoney, trackExpense, submitPerDiemExpense, createDistanceRequest, and into createTransaction.

6. src/pages/Search/SearchPageNarrow/index.tsx - Replace 28-line inline endSubmitNavigationSpans callback with useEndSubmitNavigationSpans({requireLayout: true}).

7. src/pages/Search/SearchPageWide.tsx - Replace 12-line inline callback with useEndSubmitNavigationSpans({requireLayout: false}).

8. src/libs/Navigation/helpers/dismissModalAndOpenReportInInboxTab.ts - Replace getSpan(SPAN_SUBMIT_TO_DESTINATION_VISIBLE) with isTracking() from submitFollowUpAction. Four callsites.

9. src/libs/actions/IOU/Split.ts - Replace getSpan() with isTracking() at the split bill navigation check.

10. src/libs/actions/IOU/SendMoney.ts - Replace two startSpan(SPAN_SUBMIT_TO_DESTINATION_VISIBLE) calls (sendMoneyElsewhere, sendMoneyWithWallet) with startTracking(), passing {skipSubmitExpenseSpan: true} since send-money flows don't need the submit expense span.

11. src/pages/iou/request/step/IOURequestStepCompanyInfo.tsx - Replace startSpan() with startTracking() for invoice company info submit.

12. src/libs/Navigation/Navigation.ts - Export getPreInsertedFullscreenRouteName() (needed by follow-up PR but wired here).

Test updates (5): Update mocks in GoogleTagManagerTest, dismissModalAndOpenReportInInboxTabTest, navigateAfterExpenseCreateTest, TimeExpenseConfirmationTest, IOURequestStepConfirmationPageTest to use isTracking mock instead of getSpan mock, and add getPreInsertedFullscreenRouteName to Navigation mocks.

This is all behavior-preserving. The only active path is FAST_PATH_HANDLER.DEFAULT (slow path). Fast-path dismiss-first handlers land in the follow-up PR.

What alternative solutions did you explore? (Optional)

A custom hook instead of a render-prop component for SubmitExpenseOrchestrator was considered, but the orchestrator needs to conditionally render LocationPermissionModal JSX. A hook can't own JSX, so it would push modal placement back to the parent, splitting the concern across two files again. The render-prop pattern keeps everything self-contained.