[Woo POS] Report the refund calculation flow in analytics

[samiuelson]

WOOMOB-3750

Description

The server-computed create and the classic create emit identical analytics, and the route-availability fallback emits nothing at all. During the woo_pos_server_refunds rollout that leaves us blind: no measure of server-flow adoption, no way to compare failure rates between the two flows, and no telemetry to attribute a "the totals look wrong" report to either one.

Mirrors the iOS change in woocommerce-ios#17716; the property name and values match so the funnels stay comparable across platforms.

Three additions:

• refund_flow on the refund processing events. RefundProcessingStarted, RefundProcessingSuccess and RefundProcessingFailed become data classes carrying refund_flow (local / server_computed), with the values in a new WooPosAnalyticsEventConstant.RefundFlow enum. The value comes from isServerComputedRefundConfirmed(), extracted from buildSubmissionRequest so the reported flow is decided by the same predicate the submission path branches on and cannot drift from the path actually taken. Success and failure derive it from request.serverLineItems, the documented discriminator on the request.
• api_error_code on RefundProcessingFailed. WooPosRefundSubmissionState.Failure gains an apiErrorCode field, populated from WooError.apiErrorCode where the backend refund result is handled. The message alone cannot do this — it is localized to the store and varies by wording, so deterministic server rejections were indistinguishable from transport failures. The property is omitted rather than sent empty when there is no code.
• refund_server_flow_unavailable. Emitted from WooPosRefundPreview where the availability cache is marked unavailable, carrying the store's woocommerce_version (already in scope via flow.wooVersion). The version is what tells us whether the 11.1.0 gate is behaving or a store is genuinely too old. Because the cache short-circuits the resolver on later refunds, this counts stores that fell back rather than refunds.

RefundFlowStarted is deliberately left alone. It fires on the item-selection step, before the preview probe runs, so only eligibility is known there — a store that later 404s would report server_computed at start and local afterwards. Reporting a value that can be contradicted later is worse than reporting none, and the three processing events already cover the comparison we need. Worth revisiting if a start-to-outcome funnel split turns out to be needed.

Test Steps

./gradlew :WooCommerce:testVanillaDebugUnitTest --tests "com.woocommerce.android.ui.woopos.orders.details.refund.*" — 181 tests pass, including four new ones:

• the processing events report server_computed on the server-computed path,
• refund_flow is local on the classic path (the three pre-existing assertions, updated),
• the API error code is reported on a rejection,
• the fallback event fires with the store's WooCommerce version on a 404, and does not fire when the preview succeeds.

To check on device with woo_pos_server_refunds enabled: issue a POS refund on a WooCommerce 11.1.0+ store and confirm refund_processing_started carries refund_flow: server_computed; repeat on a pre-11.1.0 store and confirm refund_flow: local plus one refund_server_flow_unavailable for that store.

Note on detekt: the per-module ./gradlew :WooCommerce:detekt task fails locally with "Run failed with 1 invalid config property" on trunk as well as here, so it is not a usable local check. ./gradlew detektAll — the task CI runs — works, and did flag a real SpacingBetweenDeclarationsWithComments violation in this branch, now fixed.

Images/gif

N/A — no UI changes.

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[dangermattic]

	1 Warning
⚠️	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.

Generated by 🚫 Danger

[claude]

AI Code Review - No issues found. The changes look good.

The PR adds analytics instrumentation to the POS refund flow (a refund_flow local/server-computed dimension, the api_error_code on failures, and a new refund_server_flow_unavailable fallback event). Verified: error.apiErrorCode resolves correctly (error = result.error), AnalyticsTracker.KEY_API_ERROR_CODE exists, the raw "woocommerce_version" key matches existing events in the same file, and isServerComputedRefundConfirmed() / refundFlowFor(request) cannot drift because forComputedCreate returns a non-null list on the server branch. Unit tests cover both the local and server-computed flows plus the API-error-code failure path.

PR housekeeping

• Applied repo-specific POS analytics guidance from AGENTS.md (WooPos* events use WooPosAnalyticsTracker / WooPosAnalyticsEvent, plain ViewModel).

---

_{Automatic review · claude-opus-4-8 · Workflow run}

_{How to reply to a finding}

Reply on this review (or inline at the line the finding refers to) with one of:

• @claude addressed - I made the change. Bot verifies against the next diff before marking resolved.
• @claude rejected: <reason> - Will not fix; reason gets quoted on the next review.
• @claude not-applicable - Finding does not apply (wrong file, already covered elsewhere, etc.).

The bot honours these on the next review pass.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Build Number	778
	Version	25.4-rc-1
	Application ID	com.woocommerce.android.prealpha
	Commit	63e2a5e
	Installation URL	1evshk3nf4jng

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[samiuelson]

Heads-up on overlap with #16338, which is approved and will likely merge first.

Both PRs add an apiErrorCode: String? to WooPosRefundSubmissionState.Failure, with the same name and the same semantics — this PR to report it in analytics, #16338 to suppress Retry on deterministic rejections. That is convergent rather than conflicting: one field serves both, and #16338 keeps the code raw rather than pre-mapping it to WooPosRefundApiError precisely so unrecognised codes still reach analytics.

Git will still flag it as a conflict in WooPosRefundSubmissionState.kt and WooPosRefundSubmissionProcessor.kt. Resolution is to keep one copy of the field; no behaviour to reconcile. I will rebase this branch once #16338 lands.