Skip to content

[Parent] Decision Audit accuracy for batch evaluation #395

Description

@prajjwalkumar17

Summary

POST /routing/evaluate/batch broke the Decision Audit's unit of record in both directions: one healthy batch call showed up as a storm of per-entry events (a payment the router called three times listed 30–52 "events"), while a batch that failed left no audit trace at all — the request hit was recorded on entry, so a failed call read as an evaluation that started and never concluded.

End state: events are proportional to calls again. One preview event per batch call (per-entry outcomes ride in the event's details), at most one error event carrying the first failure, failed batches record their stage, an empty batch is a vacuous 200 {"results": []} success instead of a 400, and batch calls are classified into the request-level audit.

Got there in two steps: #387 first added a call_count column plus ClickHouse migration machinery; #390 + #391 then made that machinery unnecessary — the revert plus one-preview-event-per-call achieve the same proportionality with no schema change and nothing to run on existing deployments.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions