feat(analytics): count evaluation calls in the Decision Audit, not per-entry events

[prajjwalkumar17]

Description

One evaluation call records one analytics event per batch entry, so the Decision Audit listed 30–52 "events" for a payment the router had called three times. Healthy batching read as a call storm, and the noise buried the routing mismatches people open that screen for.

Traced on sandbox for pay_OR9TzfVd6AuKV8y7I9A8 (profile pro_0RzdnTKZkDHmihjtOoWu) — three calls inside 31 ms, batching 3, 7 and 7 entries:

12:49:25.219  Received batch routing evaluation request, entry_count: 3
12:49:25.235  Received batch routing evaluation request, entry_count: 7
12:49:25.250  Received batch routing evaluation request, entry_count: 7

That is 3 request-hits + 17 per-entry events, before confirm or a checkout refresh add theirs.

Count calls, not entries

Summaries now carry call_count = uniq(request_id) beside event_count, in all three paths that produce a summary row: the materialized state, the raw fragment, and the exact lookup. The Matches row reads 3 calls · 17 entries, and the trace groups under collapsible per-call headers keyed on request_id — the same key the server counts with, so the list and the trace always agree.

Per-entry events are kept, not collapsed. They carry the per-payment-method decisions the list's own filters (has(gateways, ?), has(statuses, ?)) and the inspector are built on, and three other screens read the same response shape. What changed is what gets counted and headlined.

An empty batch is a vacuous success

requests: [] returned TE_04 400, which made the router record a failed routing event and fall through to its single-evaluation path on every session/PML call from a card-only cut-over profile. It now answers 200 {"results": []}. The positional contract holds trivially and the caller's length check passes 0 == 0, so the fallback stops firing without waiting on a router release.

The router should still skip the call — a one-line guard in decision_engine_routing_batch_with_fallback, mirroring the one its shadow path already has. This just stops the engine being noisy about it meanwhile.

Batch API events

POST /routing/evaluate/batch had no classify_request arm, so batch calls were invisible to the request-level audit the single endpoint has always fed.

Migration

clickhouse/scripts/039_audit_call_counts.sh — additive and idempotent.

Do not re-run 025 for this. It opens with DROP TABLE on the audit summary tables; against a live database that discards every accumulated summary and the Matches list empties out until traffic refills it. 039 instead does ALTER ... ADD COLUMN IF NOT EXISTS (not in the sorting key, so metadata-only, no re-sort) and rebuilds only the materialized view, whose SELECT cannot be ALTERed. Dropping a MV leaves its target table's rows untouched, so all history is preserved. It asserts the view is back afterwards, so a half-applied migration fails the deploy instead of silently stopping the summaries pipeline.

Nothing needs running by hand. 039 joins the oneclick.sh heal loop beside 038 (initdb scripts only run on a fresh volume, so the column would otherwise never reach an existing deployment), with the matching column-drift probe.

No deploy ordering to get right. The reader probes system.columns and omits the column when absent, substituting a 0 the caller reports as the event count. Only the positive answer is latched — a negative is re-probed every five minutes, so the page starts counting calls on its own once 039 lands, with no pod restart.

State	Behaviour
Deployed, 039 not yet run	Page works; Matches shows event counts; trace grouping already works (grouped client-side)
After 039	Matches shows N calls · M entries for payments seen since
Rows predating 039	Empty state finalizes to 0 → reported as the event count
Fresh volume	Nothing to do; 025 creates the column and 039 exits

How did you test it

End to end against sandbox (merchant_1703154093), plus unit tests.

Check	Result
cargo test --lib	343/343
cargo clippy --lib	clean
tsc --noEmit + vite build	clean
sh -n on 039 and oneclick.sh	clean
Volume split across two same-connector MCAs, 6 payments	4/2 across both MCAs
Cut-over profile decide path	routing_source=decision_engine, routed per the DE rule
Empty-batch path (card-only cut-over profile)	reproduced the 400 + fallback warn this removes

Not verified: the grouped-timeline rendering is covered by type-check and production build, not by a run against live data — the audit page needs a backend with traffic. I'd like to drive it on sandbox once this deploys. The empty-batch handler has no handler-level test; the repo has no HTTP-handler harness and neighbouring endpoints are in the same position. The logic that can be tested without one — fragment SQL, the pre-migration fallback, the classify arm — is.

Split out of this PR

A per-payment routing decision cache was developed on this branch and removed before review. It puts 2N sequential awaited Redis round-trips on the payment path with no kill switch, and it suppresses the very events call_count counts (a fully-cached call would record nothing, so "3 calls" would display as "2"). It will come back separately, behind a config flag and with the round-trips batched. Nothing here depends on it.

🤖 Generated with Claude Code

Closes #402

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.