Don't attach volume telemetry to pre-submission failures

[JakeUrban]

Summary

Follow-up to #2984. Don't attach volume telemetry to a pre-submission failure event.

Found while implementing the same telemetry on mobile (stellar/freighter-mobile#996) and checking the two clients against each other.

🤖 Generated with Claude Code

[github-actions]

PR Preview build is ready: https://github.com/stellar/freighter/releases/tag/untagged-2cfef3933c62e06d8327
Backend: V1 prod + V2 beta (no sandbox configured for @JakeUrban). SDF collaborators only — install instructions in the release description.

[Copilot]

Pull request overview

Prevents USD volume fields from being attached to signing failures.

Changes:

• Detects signing failures before submission.
• Emits failure-only telemetry and transitions the UI to an error state.
• Adds regression coverage for software and hardware signing failures.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
transactionSubmission.ts	Adds an explicit submission-error action.
useSubmitTxData.tsx	Separates pre-submission failures from submitted outcomes.
useSubmitTxData.telemetry.test.tsx	Tests failure telemetry and submission guards.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[CassioMG]

Two doc comments invalidated by the snapshot-timing change

Docs only — no behavior impact; not a merge blocker.

TL;DR: Moving the price snapshot to after signing leaves two load-bearing comments describing the old flow. The snapshot helper's own doc still says the fetch is "started at confirmation", while this PR's call site now correctly says the opposite ("after signing succeeded and immediately before submission") — a reader of the helper alone gets the wrong contract. And the failure screen's comment explaining why it emits no telemetry still claims the central emit site always has the price snapshot and transaction result in scope, which is no longer true for the new pre-submission failure path that emits with neither. Both are two-line comment fixes; these docs were relied on heavily during the parent PR's review, so keeping them truthful is worth the diff.

---

Detailed explanation (for agents)

(a) confirmationPriceSnapshot.ts module doc still reads "Issues ONE price fetch covering every leg's canonical id, started at confirmation and never blocking signing/submission" — its sole caller now starts it post-signing. The cachedDisplayPrices sentence ("captured by the caller at this same moment... 'the price already shown to the user'") also loosened: post-signing, the display cache may have refreshed during a password prompt or hardware approval, so the fallback is no longer guaranteed to be confirm-click state:

freighter/extension/src/helpers/confirmationPriceSnapshot.ts

Lines 41 to 50 in 2195971

	/**
	* Issues ONE price fetch covering every leg's canonical id, started at
	* confirmation and never blocking signing/submission — callers do not await
	* this. `cachedDisplayPrices` is the price map already held for the on-screen
	* fiat estimate, captured by the caller at this same moment: it must reflect
	* "the price already shown to the user for this transaction", not whatever
	* the cache holds later when `resolve()` is called.
	*
	* Cancellation is a real network abort on the v1 endpoint (a direct fetch).
	* The v2 endpoint runs in the background service worker across a message

The updated call-site comment it now contradicts:

freighter/extension/src/popup/components/InternalTransaction/SubmitTransaction/hooks/useSubmitTxData.tsx

Lines 258 to 266 in 2195971

	// Everything the volume telemetry needs is snapshotted here — after
	// signing succeeded and immediately before submission, so the prices sit
	// as close as possible to the transaction's actual execution time.
	// Amounts and prices are frozen together and carried to whichever
	// terminal event fires. Skipped entirely for collectible sends (unpriced,
	// out of scope) and for custom networks (not real economic activity,
	// shouldn't pollute volume metrics).
	const cachedDisplayPrices =
	allTokenPricesCache[networkDetails.networkPassphrase]?.[publicKey] ??

(b) SubmitFail/index.tsx centralization comment — the conclusion (single emit site, no double-counting) still holds, but the supporting rationale "it already has the confirmation price snapshot and the transaction result in scope" is false for the new !isSigned branch, which emits paymentFailed/swapFailed/collectibleSendFailed before any snapshot is started and without a transaction result:

freighter/extension/src/popup/components/InternalTransaction/SubmitFail/index.tsx

Lines 31 to 40 in 2195971

	// Renders the user-facing failure screen only — title, explanatory
	// notification, and any error-specific messaging/links, chosen by
	// classifying `error` into a RESULT_CODES case below. It does not emit
	// telemetry: paymentFailed / swapFailed / collectibleSendFailed are NOT
	// emitted here. They used to be, from an effect keyed on `error`/`asset`/etc
	// — but that re-fires on every remount (double-counting attempted volume).
	// useSubmitTxData's fetchData is the single, centralized emit site for every
	// terminal event (success and failure alike): it already has the
	// confirmation price snapshot and the transaction result in scope, and it
	// runs exactly once per submission attempt.

Suggested fix: reword (a) to "started once signing succeeds, immediately before submission, never blocking submission" and adjust the cachedDisplayPrices sentence accordingly; reword (b)'s rationale to note the pre-submission failure path deliberately emits without snapshot/result.

[CassioMG]

This LGTM - other than the stale-docs comment

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (1)

extension/src/popup/components/InternalTransaction/SubmitTransaction/hooks/useSubmitTxData.tsx:260

• Starting the snapshot only after signing changes the meaning of successful-event USD data: rates can now be fetched after the confirmation-time value has moved. Both #2984 and the linked mobile implementation define this snapshot as frozen before signing so telemetry reflects what the user confirmed. Omitting volume from a signing failure does not require moving the snapshot; start it before signing, then cancel it on !isSigned and emit that failure without resolving or spreading the USD properties.

      // Everything the volume telemetry needs is snapshotted here — after
      // signing succeeded and immediately before submission, so the prices sit
      // as close as possible to the transaction's actual execution time.