fix(exchange): interactive AWS/Azure RI exchange endpoints persist no ri_exchange_history row, so their spend bypasses the daily-cap accounting #145

Summary

The interactive RI-exchange endpoints execute a real, billed exchange and then persist nothing. No ri_exchange_history row is written. Because GetRIExchangeDailySpend computes the daily spend cap by summing exactly that table, an interactive exchange also contributes zero to the daily-cap accounting that the automated exchange path relies on.

This applies to both interactive endpoints, AWS and Azure. It is not Azure-specific — the split is interactive vs automated, not provider vs provider. That framing matters for the fix, and it is the opposite of what I expected when I started tracing.

Open question, and the reason this is labelled status/needs-info: I could not determine from the code alone whether this is a deliberate scope boundary — the interactive flows are session-based and return the exchange/session ID straight to the caller, so an argument exists that the ledger is meant to track only automated runs — or a genuine omission. The priority below hinges on that answer and should be re-triaged once a human resolves it. I have deliberately not guessed. If the omission is unintentional, this is materially more serious than the p2 I have assigned.

Evidence

Azure interactive path — internal/api/handler_ri_exchange.go:1002 executeAzureExchange:

result, err := client.ExecuteExchange(ctx, preview.SessionID)   // line 1037 — money moves here
if err != nil { ... }

logging.Infof("azure ri-exchange executed: subscription=%s session=%s status=%s", ...)  // line 1043

return &AzureExecuteExchangeResponse{ ... }, nil                 // line 1045

After the exchange is executed and billed, the only trace is a log line. Then it returns.

AWS interactive path — same file, the handler executing at line 1595:

exchangeID, quote, err := exchange.ExecuteExchange(ctx, exchange.ExchangeExecuteRequest{ ... })
if err != nil { ... }

return &ExchangeExecuteResponse{ ExchangeID: exchangeID, Quote: quote }, nil

Also no persistence. And it cannot persist: ExchangeExecuteRequest (pkg/exchange/exchange.go:86) carries no store, and func ExecuteExchange(ctx context.Context, req ExchangeExecuteRequest) (pkg/exchange/exchange.go:286) takes no store either.

Confirming the absence mechanically: grep -nE "\.store\.|Store\.|Save[A-Za-z]*\(|Insert|Persist" internal/api/handler_ri_exchange.go returns no matches at all.

The only writer is the automated path. SaveRIExchangeRecord (internal/config/store_postgres.go:2502) is reached solely through the adapter at internal/server/handler_ri_exchange.go:291, called only from pkg/exchange/auto.go (lines 390, 456, 629) inside RunAutoExchange.

Why this is more than a missing audit row

GetRIExchangeDailySpend (internal/config/store_postgres.go:2779) is the daily cap:

SELECT COALESCE(SUM(payment_due), 0)::text
FROM ri_exchange_history
WHERE status IN ('completed', 'processing')
  AND COALESCE(completed_at, updated_at) >= date_trunc('day', $1::timestamptz AT TIME ZONE 'UTC')
  ...

It sums the ledger and nothing else. The automated path treats that write as load-bearing — pkg/exchange/auto.go:417:

// maxLedgerAttempts is the number of times processAutoExchange retries a
// SaveRIExchangeRecord write after money has moved. Persistent failure halts
// the run to prevent subsequent exchanges from bypassing the daily cap
// (GetRIExchangeDailySpend sums the ledger rows that this write would create).
const maxLedgerAttempts = 3

So the automated path retries the ledger write three times and halts the entire run if it cannot land, explicitly to stop later exchanges bypassing the daily cap. The interactive paths skip that write entirely and never consult the cap at all (GetRIExchangeDailySpend has no caller in internal/api/).

Consequences, in order of severity:

1. Interactive exchange spend is invisible to the daily cap. An operator can execute interactive exchanges all day; every subsequent automated run still sees full daily headroom, because the cap sums a table those exchanges never wrote to. The guardrail the automated path halts itself to protect is silently bypassed from the side.
2. No audit row for a completed money movement. Nothing in ri_exchange_history records that the exchange happened, who approved it, or what was paid.
3. No audit-gap signal either. The sibling purchase_history path treats a lost audit row as a defect in its own right and surfaces it — recordHistoryAuditGap (internal/purchase/execution.go:686) stamps a history_write_failed marker and the API reports IsAuditGap=true (internal/api/handler_history.go:416). The interactive exchange paths have no equivalent, so the absence is not merely unrecorded, it is unreported.

To be fair to the current design: the interactive paths are not unguarded. Both enforce a per-call cap — Azure via checkAzureExchangeMoneyGuardrails against maxRat/body.Currency, AWS via MaxPaymentDueUSD (and ExecuteExchange refuses outright without it, pkg/exchange/exchange.go:287), plus requirePermissionConstraints with MaxPurchaseAmount. The gap is specifically in the daily aggregate, not the per-call check.

Suggested direction

Depends entirely on the open question above:

• If the omission is unintentional: have the interactive handlers write a ri_exchange_history row after a successful execution, with the same after-money-has-moved retry discipline as maxLedgerAttempts, and an audit-gap marker mirroring recordHistoryAuditGap when the write ultimately fails. Note that the Azure case is blocked on LeanerCloud/cloud-commitments-cli#1676 — ri_exchange_history.account_id is VARCHAR(20) with a CHECK (account_id ~ '^\d{12}$'), so an Azure subscription GUID would be rejected on both width and the regex. LeanerCloud/cloud-commitments-cli#1676 must land first, and widening alone is not enough there.
• If it is deliberate: document it at both handlers and, more importantly, at GetRIExchangeDailySpend, stating that the daily cap covers automated exchanges only and does not bound total exchange spend. Right now nothing says so, and the maxLedgerAttempts comment reads as though the ledger is authoritative for all exchange spend.

Related

• LeanerCloud/cloud-commitments-cli#1676 — ri_exchange_history.account_id is VARCHAR(20) + an AWS-shaped CHECK. Latent today precisely because of this issue: the Azure path never writes a row, so the too-narrow column is never exercised. Fixing this issue without LeanerCloud/cloud-commitments-cli#1676 would turn that latent defect live.
• fix(db): purchase_history.account_id VARCHAR(20) drops the audit row after every Azure/GCP purchase cloud-commitments-cli#1603 — the same class of defect on purchase_history.account_id, which was reachable and did lose audit rows for billed Azure/GCP purchases.

Found while auditing sibling columns for LeanerCloud/cloud-commitments-cli#1603.