[Metrics] Add submit-to-destination-visible span for expense creation flows

[JakubKorytko]

Explanation of Change

Adds a new Sentry span that measures the full time from when the user submits an expense until the destination page is fully rendered and visible. This addresses the gap where we had no end-to-end visibility for most post-creation navigation paths.

What's measured

• Start: Submit on the expense confirmation step (IOURequestStepConfirmation.tsx), or from Send Money (Amount step, skip confirmation) or Send Invoice (Company Info step) when those flows submit without going through confirmation.
• End: When the destination screen’s main content has laid out (e.g. onLayout of the primary list/view), so the user can see the result.
• Duration: Includes optimistic updates, modal dismiss, navigation, and destination render. Target is 400ms.

Coverage

• One new span: ManualSubmitToDestinationVisible (constant: SPAN_SUBMIT_TO_DESTINATION_VISIBLE), started with the same attributes as the existing submit span (scenario, has_receipt, from_global_create, iou_type, request_type). The span is tagged with submit_follow_up_action (one of: dismiss_modal_and_open_report, navigate_to_search, dismiss_modal_only) so we can segment by outcome.
• Where the span is ended: When the follow-up action is complete and the target is visible:
  • dismiss_modal_and_open_report - ReportScreen or SearchMoneyRequestReportPage when they gain focus or layout (report or recipient chat became visible).
  • navigate_to_search - Search list onLayout (with existing markNavigateAfterExpenseCreateEnd).
  • dismiss_modal_only - In dismissModalAndOpenReportInInboxTab after InteractionManager.runAfterInteractions, or when ReportScreen / SearchMoneyRequestReportPage is already visible and we only dismissed the modal (they end the span in their focus/layout callbacks).

How destination is known

• State lives in the telemetry module submitFollowUpAction.ts (no Onyx). Before each post-expense-create navigation we call setPendingSubmitFollowUpAction(followUpAction, reportID?). We only set pending (and run span-ending logic) when the span was actually started - e.g. Send Money or Send Invoice from a step that starts the span; flows that never start the span (e.g. skip-confirmation Send Money before we added span start there) do not set pending.
• Target screens call getPendingSubmitFollowUpAction() in their callback (e.g. useFocusEffect or onLayout); when the result matches they call endSubmitFollowUpActionSpan(followUpAction, reportID), which clears the pending state and sets the submit_follow_up_action attribute on the span.
• Split-with-receipt: The startSplitBill() path (e.g. from the confirmation step with receipts) sets the pending action to DISMISS_MODAL_AND_OPEN_REPORT before calling Navigation.dismissModalWithReport, so the span is ended when the report screen appears.
• Validation: endSubmitFollowUpActionSpan only ends the span if the passed followUpAction (and reportID when applicable) matches the current pending action; this avoids races and keeps attribution correct.
• Search cancel: Search only calls cancelSubmitFollowUpActionSpan() when the pending action is NAVIGATE_TO_SEARCH (e.g. when bailing to error/empty/chart view). If the pending action is DISMISS_MODAL_ONLY, we don’t cancel - the deferred endSubmitFollowUpActionSpan(DISMISS_MODAL_ONLY) in dismissModalAndOpenReportInInboxTab will end the span.

Existing spans (SPAN_SUBMIT_EXPENSE, SPAN_NAVIGATE_AFTER_EXPENSE_CREATE) are unchanged; this adds a single end-to-end metric for all expense types and all destinations.

Fixed Issues

$ #83634
PROPOSAL: N/A

Tests

Submit follow-up action types (what the span’s submit_follow_up_action attribute means):

• **dismiss_modal_and_open_report** - You were somewhere else in the app and the app re-navigated you to a report (e.g. report chat or money request report). The modal was dismissed and a report screen became visible.
• **navigate_to_search** - You were not on Inbox; the app navigated you to the Search/Reports page and the new expense is shown there.
• **dismiss_modal_only** - Submitting only dismissed the modal (e.g. you were already on the target report or on Search ROOT / Expenses). No new screen was opened; you stayed where you were or the modal just closed. (If you were on another Search sub-tab, e.g. Chats, the app navigates to Search ROOT/Expenses, so that is navigate_to_search.)

Test cases

1. dismiss_modal_and_open_report - Do an action using one of the triggers below. In Sentry (or local logs), confirm a ManualSubmitToDestinationVisible span with submit_follow_up_action: dismiss_modal_and_open_report, and when applicable report_id, plus the submit attributes (scenario, has_receipt, from_global_create, iou_type, request_type).

• From Inbox with no report open or with report A open (you will do an action that opens report B)
  • Global create and submit the expense to report B.
  • Start a split bill flow and submit so the app opens report B.
  • Start send invoice flow and send so the app opens report B.
  • Track an expense and submit so the app opens report B.
• Start Send Money flow to a recipient while not on that recipient's chat and submit so the app opens that recipient's chat.

2. navigate_to_search - Do an action using one of the triggers below. In Sentry (or local logs), confirm a ManualSubmitToDestinationVisible span with submit_follow_up_action: navigate_to_search and the submit attributes above.

• On a tab other than Inbox and other than Reports (e.g. Workspaces, Account, Home) do one of the following; the app navigates to the Search (Reports) page.
  • Global create and submit an expense.
  • Start a split bill flow and submit.
  • Start send invoice flow and send.
  • Track an expense and submit.

3. dismiss_modal_only - Do an action using one of the triggers below. In Sentry (or local logs), confirm a ManualSubmitToDestinationVisible span with submit_follow_up_action: dismiss_modal_only and the submit attributes above.

• On Search ROOT (Expenses sub-tab) as the current screen, submit an expense (modal closes, you stay on Search ROOT). If you were on another Search sub-tab (e.g. Chats), the app navigates to Expenses, so that is navigate_to_search.
• From Inbox with no report open or with report A open (you will do an action that affects report A)
  • Global create or from-report create and submit the expense to report A.
  • Start a split bill flow and submit so the app stays on report A (e.g. split expense added to report A).
  • Start send invoice flow and send so the app stays on report A (e.g. invoice sent to same room).
  • Track an expense and submit so the app stays on report A.
• From Inbox with Report A open in wide RHP add an expense to report A and submit; app only pops/dismisses the modal.
• Start Send Money flow to a recipient while on that recipient's chat and submit; app only pops/dismisses the modal.

Note: When using a recent action in step 2, the app may redirect to Inbox instead of the Search/Reports page. That does not mean the PR is broken - the span correctly attributes the outcome (e.g. dismiss_modal_and_open_report when a report opens, not navigate_to_search).

Offline tests

Same as tests though data is only sent to Sentry while being online.

QA Steps

Same as tests.

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
    • If any non-english text was added/modified, I used JaimeGPT to get English > Spanish translation. I then posted it in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• I verified that if a function's arguments changed that all usages have also been updated correctly
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

Example flow runs

dismiss_modal_and_open_report

dismiss_modal_and_open_report.mp4

dismiss_modal_only

dismiss_modal_only.mp4

navigate_to_search

navigate_to_search.mp4

[mountiny]

@codex review

[codecov]

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/CONST/index.ts	94.30% <ø> (ø)
...equestReportView/MoneyRequestReportActionsList.tsx	56.92% <ø> (ø)
src/components/ReportActionsSkeletonView/index.tsx	100.00% <100.00%> (ø)
src/libs/actions/IOU/SendInvoice.ts	96.61% <100.00%> (+0.02%)	⬆️
...es/iou/request/step/IOURequestStepConfirmation.tsx	57.48% <100.00%> (+0.15%)	⬆️
...stReportView/MoneyRequestReportTransactionList.tsx	1.14% <0.00%> (ø)
...tReportView/SearchMoneyRequestReportEmptyState.tsx	3.44% <0.00%> (ø)
src/hooks/useSubmitToDestinationVisible.ts	87.50% <87.50%> (ø)
src/libs/actions/IOU/Split.ts	77.79% <66.66%> (-0.05%)	⬇️
src/pages/Search/SearchMoneyRequestReportPage.tsx	0.00% <0.00%> (ø)
... and 8 more
... and 29 files with indirect coverage changes

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b646417f8a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[mountiny]

Review

Overall this looks solid — the concept of measuring end-to-end submit-to-destination-visible is valuable, and the destination-type bucketing will make the data actionable. A few points to consider:

Major: NVP_ prefix

NVP_PENDING_EXPENSE_CREATE_DESTINATION is purely local telemetry state, never synced to the server. The NVP_ prefix conventionally denotes server-synced Name-Value Pairs in this codebase. There is some precedent for local-only keys using this prefix (e.g. NVP_DELETE_TRANSACTION_NAVIGATE_BACK_URL), but dropping the prefix would be more accurate.

RHP_POP on narrow screens — does onLayout actually fire?

When Navigation.pop(rhpKey) runs, the underlying ReportScreen is already mounted and its wrapper View is already laid out. onLayout only fires when a View's dimensions change. On narrow/mobile screens, the RHP is a full-screen overlay — popping it doesn't change the underlying ReportScreen's layout dimensions, so onLayout likely won't fire and the span would never be ended for the rhp_pop destination type.

On wide screens the RHP occupies side space, so popping it may change available width and trigger onLayout. But on mobile this seems like it could be a gap. Worth verifying with a quick test on a narrow screen.

Minor: destinationType in OnyxValuesMapping is typed as plain string

In ONYXKEYS.ts, the type is {destinationType: string; reportID?: string}. Consider using DestinationType (ValueOf<typeof CONST.TELEMETRY.DESTINATION_TYPE>) instead of string for type safety — it would catch typos and make the allowed values discoverable.

Minor: re-export indirection

IOU/Split.ts imports setPendingExpenseCreateDestination from @libs/telemetry/markSubmitToDestinationVisibleEnd rather than from @libs/actions/ExpenseCreateDestination (the canonical source). This blurs the action/telemetry boundary. Consider importing directly from the action file.

[mountiny]

Also is there a way to avoid using the onyx key to keep track of the span?

[JakubKorytko]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: db788bb84a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[JakubKorytko]

Thanks for the review @mountiny

Major: NVP_ prefix
I’ve stopped using an Onyx key for this. The “pending destination” is now stored in a module-level variable in the telemetry module (submitToDestinationVisible.ts), so there’s nothing to sync and no NVP naming.

RHP_POP on narrow screens
I’ve switched to ending the span from useFocusEffect in ReportScreen instead of onLayout. When the RHP is popped, the central ReportScreen was already mounted and its layout size doesn’t change on narrow screens, so onLayout doesn’t run again there. onLayout does fire on mount and on layout changes, but in this flow we get neither when the RHP is popped. Relying on focus (useFocusEffect) fixes that: when the RHP is removed, the central pane gains focus and we end the span there. I’ve removed the onLayout handler for this telemetry in ReportScreen and use only useFocusEffect.

Minor: destinationType typing
I removed the Onyx key and its mapping. The type now lives in the telemetry module as DestinationType (from CONST.TELEMETRY.DESTINATION_TYPE).

Minor: re-export indirection
I’ve inlined the former action module into the telemetry module. The “actions” dir is for Onyx actions, and this state is in-memory telemetry only, so it now lives in submitToDestinationVisible.ts. Callers import setPendingExpenseCreateDestination and getPendingExpenseCreateDestination from that file; there’s no re-export.

Avoiding the Onyx key
I did this via a module-level variable, getPendingExpenseCreateDestination() for destination screens to read in their callbacks (no subscription), and I reset the “already ended” ref in the useFocusEffect cleanup (on blur) so the same screen can end the span again on a later submit.

---

Follow-up: Set pending destination for split-with-receipt submits
Agreed. The startSplitBill() path (called from the confirmation step when splitting with receipts) was calling Navigation.dismissModalWithReport without setting the pending destination, so the span stayed open. I now call setPendingExpenseCreateDestination(CONST.TELEMETRY.DESTINATION_TYPE.REPORT_CHAT, splitChatReport.reportID) in startSplitBill in Split.ts immediately before dismissModalWithReport, so the report chat destination can end the span when it becomes visible.

Follow-up: Validate destination before closing submit-visible span
Agreed. I added a check at the start of markSubmitToDestinationVisibleEnd: we only end the span if the current pending destination’s destinationType (and reportID when present) matches the arguments passed by the caller. If they don’t match, we return without ending. That prevents another screen (e.g. Search) from closing the span with the wrong destination_type when there’s a race with a deferred path like MODAL_DISMISS.

[melvin-bot]

@QichenZhu Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2955c6a0a6

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[trjExpensify]

PR doesn’t need product input as a Sentry metrics PR. Unassigning and unsubscribing myself.

[JakubKorytko]

@codex review

[JakubKorytko]

Hi, @mountiny @QichenZhu the PR is ready for another review. I changed the structure a bit - refactored from destination_type to submit_follow_up_action, so instead of five screen-based values there are now three action-based ones (dismiss_modal_and_open_report, navigate_to_search, dismiss_modal_only). The test cases were updated to match. The old structure was misleading, hard to debug and not very clean - the new one should be a lot clearer.

Videos of the particular flows are in the PR videos section instead of screenshots. I've tested it with debugTransport as well but for video being cleaner and shorter I've added sentry log here

Reason was to segment by what actually happened after submit (opened a report, went to Search, or just dismissed) as it matters the most rather than by screen names. I also fixed a two edge cases along the way:

• skip-confirmation flows (Send Money, Invoice) now start the span so they don’t leave stale state,
• the attribute is set on the span as soon as pending is set so it’s there even if the span gets cancelled,

[chatgpt-codex-connector]

Codex Review: Something went wrong. Try again later by commenting “@codex review”.

We were unable to download your code in a timely manner.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[mountiny]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d178715622

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[QichenZhu]

Thanks! All three test cases work for me now.

Do the durations look good?

1. dismiss_modal_and_open_report

Duration: 2040ms

2. navigate_to_search

Duration: 2674ms

3. dismiss_modal_only

Duration: 326ms

[mountiny]

Hard to say from the screenshots but that is possible

[QichenZhu]

Just FYI, I once got a weird duration of 1772861539340ms (milliseconds since 1970) but couldn't reproduce it a second time.

[QichenZhu]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
  • I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
  • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
  • I verified the JSDocs style guidelines (in STYLE.md) were followed
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
• I verified any variables that can be defined as constants (ie. in CONST.ts or at the top of the file that uses the constant) are defined as such
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

1. dismiss_modal_and_open_report

2. navigate_to_search

####3. dismiss_modal_only

Android: mWeb Chrome

1. dismiss_modal_and_open_report

2. navigate_to_search

####3. dismiss_modal_only

iOS: HybridApp

1. dismiss_modal_and_open_report

2. navigate_to_search

####3. dismiss_modal_only

iOS: mWeb Safari

1. dismiss_modal_and_open_report

2. navigate_to_search

####3. dismiss_modal_only

MacOS: Chrome / Safari

1. dismiss_modal_and_open_report

2. navigate_to_search

####3. dismiss_modal_only

[QichenZhu]

Just added some minor style suggestions. @staszekscp's and codex's comments are more important though.

[JakubKorytko]

Just FYI, I once got a weird duration of 1772861539340ms (milliseconds since 1970) but couldn't reproduce it a second time.

I've seen that before too, but not only in this PR and also had a negative number two times (-X ms). You can see on the screenshot you sent that ManualCreateExpenseSubmit already has this number of ms before this PR span is fired and later Skeleton Activity has it too. I doubt it's this PR fault and I have no clue how to reproduce.

But I will of course address the PR comments.

[JakubKorytko]

@mountiny all comments addressed, @QichenZhu may you please take a final look and complete the checklist?

[mountiny]

Going to move this forward as all the requested changes seem to be addressed

[github-actions]

🚧 @mountiny has triggered a test Expensify/App build. You can view the workflow run here.

[github-actions]

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #84069.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-e5cd992-16295ce-b076ea507913ff4bf69e61f411109d0794fb1b33/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-e5cd992-16295ce-ca6a4964b40db82d1a603735ace9538a52b17627/index.html

Web 🕸️
https://84069.pr-testing.expensify.com

---

👀 View the workflow run that generated this build 👀

[JakubKorytko]

FYI found RCA of huge/negative Sentry duration values, posted here: #83495 (comment)

[OSBotify]

🚀 Deployed to staging by https://github.com/mountiny in version: 9.3.35-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

[izarutskaya]

Hi @mountiny @JakubKorytko QA team can't check Sentry. Is it internal PR?

[luacmartins]

@izarutskaya yes, we can QA this internally

[OSBotify]

🚀 Deployed to production by https://github.com/luacmartins in version: 9.3.35-1 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅