Problem. The per-rec idempotency token is sha256(executionID + ":" + recIndex) (pkg/common/tokens.go:41, derived in internal/purchase/execution.go:428). But the Retry path mints a fresh uuid.New() execution ID (internal/api/handler_purchases.go:840), and the multi-account path mints a fresh per-account UUID (internal/purchase/execution.go:151-160). Both therefore derive a different token than the original attempt, so provider-level idempotency (AWS SP ClientToken, Azure reservationOrderID, GCP RequestId/name) cannot match → double-buy when an executor died after the provider created the commitment but before the row persisted as success.
Evidence.
internal/purchase/execution.go:428 (token derivation), :151-160 (per-account UUID)pkg/common/tokens.go:41 (DeriveIdempotencyToken)internal/api/handler_purchases.go:840 (persistRetryExecution, uuid.New())internal/purchase/reaper.go:110-113 + recovery sweep comments assert "the operator's retry hits the idempotency path" — false per above.
Impact. Direct financial loss (duplicate RI/SP/CUD purchase) on the exact recovery scenario the whole design targets. Highest-dollar case is a multi-account plan fan-out.
Suggested fix. Make idempotency identity independent of the execution ID: either (a) add an IdempotencyKey column to purchase_executions, generated once at first creation and copied verbatim into every retry/per-account successor; or (b) derive from the root lineage execution ID + account ID + rec index, propagated onto every successor row. Update reaper/recovery comments once true. Regression test: retry of a "failed" execution whose commitment landed must derive the SAME token and short-circuit.
References. Source: report 05 (C1, H1) + architecture notes. Blocks #639 (its "re-drive is double-buy-safe" premise is invalid until this lands). Related #636/#638 (idempotent creation), #197/#838 (FE multi-account seeding — UI only).
Filed from automated adversarial code review (see docs/code-review/). Source finding(s): 05-C1, 05-H1.
Problem. The per-rec idempotency token is
sha256(executionID + ":" + recIndex)(pkg/common/tokens.go:41, derived ininternal/purchase/execution.go:428). But the Retry path mints a freshuuid.New()execution ID (internal/api/handler_purchases.go:840), and the multi-account path mints a fresh per-account UUID (internal/purchase/execution.go:151-160). Both therefore derive a different token than the original attempt, so provider-level idempotency (AWS SPClientToken, Azure reservationOrderID, GCP RequestId/name) cannot match → double-buy when an executor died after the provider created the commitment but before the row persisted as success.Evidence.
internal/purchase/execution.go:428(token derivation),:151-160(per-account UUID)pkg/common/tokens.go:41(DeriveIdempotencyToken)internal/api/handler_purchases.go:840(persistRetryExecution,uuid.New())internal/purchase/reaper.go:110-113+ recovery sweep comments assert "the operator's retry hits the idempotency path" — false per above.Impact. Direct financial loss (duplicate RI/SP/CUD purchase) on the exact recovery scenario the whole design targets. Highest-dollar case is a multi-account plan fan-out.
Suggested fix. Make idempotency identity independent of the execution ID: either (a) add an
IdempotencyKeycolumn topurchase_executions, generated once at first creation and copied verbatim into every retry/per-account successor; or (b) derive from the root lineage execution ID + account ID + rec index, propagated onto every successor row. Update reaper/recovery comments once true. Regression test: retry of a "failed" execution whose commitment landed must derive the SAME token and short-circuit.References. Source: report 05 (C1, H1) + architecture notes. Blocks #639 (its "re-drive is double-buy-safe" premise is invalid until this lands). Related #636/#638 (idempotent creation), #197/#838 (FE multi-account seeding — UI only).
Filed from automated adversarial code review (see docs/code-review/). Source finding(s): 05-C1, 05-H1.