[IAmJSD]

Summary

This PR fixes one boundary of #361: the purchases spend cap. MaxPurchaseAmount on a group permission, or max_amount on an API key, is denominated in USD. Before this PR it was compared against the raw amount of a purchase in any currency. The other boundaries are listed in the table below.

Refs #361

Root cause

The cloud-commitments-go side of the class (go#124, closed) added common.Recommendation.CommitmentCurrency. The pinned AWS parsers set it for RIs and Savings Plans, and so do the pinned GCP Compute Engine, Cloud SQL and Memorystore clients. The platform lost it at the first boundary:

• scheduler.convertRecommendations built a config.RecommendationRecord with no currency field, so the stored recommendation, the execution row and every rec handed to enforcePurchaseConstraints carried bare numbers.
• purchaseConstraintSets then put the batch's total commitment into MaxPurchaseAmount. The auth matcher compared it against the USD cap.

The result: a purchase priced at 2,400 EUR passed an approve-any cap of 2,400 USD (2400 <= 2400) and was bought. In general, whichever way the exchange rate points, the comparison either lets through a purchase over the operator's ceiling or refuses a legal one.

Fix

• internal/config/types.go: new RecommendationRecord.CommitmentCurrency (commitment_currency). It is persisted inside the recommendations row's JSONB payload and the execution's recommendations JSONB. No DDL and no migration. An empty value means unknown. It is never defaulted to USD.

• internal/scheduler/scheduler.go: convertRecommendations copies the provider's CommitmentCurrency onto the record.

• internal/planstep/resolve.go: size takes the currency from the stored row it prices from, not from the displayed row. The costs are the stored row's, so their currency must be too.

• internal/api/purchase_currency.go (new) and enforcePurchaseConstraints: if any rec in the batch is not provably USD (another currency, or empty or whitespace), the constraint sets are checked with an amount the matcher can never satisfy (math.MaxFloat64).

  • A grant that carries any MaxPurchaseAmount refuses the batch with a 403 that names the currency. The message still contains "constraints".
  • A grant with no amount cap still allows it.
  • If another dimension (account, provider, service, region, or a malformed negative cap) also refuses the batch, that dimension's own error is returned, as before.
  • An auth backend error is returned unchanged and not retried.

  This is the same rule checkAzureExecuteConstraints already applies on the Azure RI exchange path. Because enforcePurchaseConstraints is the single choke point, the rule covers every money path that calls it:

  • web execute
  • direct execute (execute-any/own)
  • session approve and token approve (approve-any/own)
  • run-now
  • retry
  • all four post-claim re-checks (claimed_row_check.go)

• Where the currency comes from. priceFromStored copies the stored row (out := *stored), so the currency used on the web execute path is the stored one. A request body that says "commitment_currency":"USD" cannot lift the refusal, and a test pins this.

I chose fail-closed over conversion because the issue rules out FX conversion and a currency field on the cap ("deliberately not in scope", PR #1515). A guardrail that cannot establish the denomination of the amount it checks has not checked anything.

Boundaries of #361: status after this PR

Boundary	Where	Status
Purchases MaxPurchaseAmount / API-key max_amount vs rec amounts	enforcePurchaseConstraints (all purchase money paths)	Fixed here
Recommendation currency dropped at collection	scheduler.convertRecommendations	Fixed here
Plan-step pricing takes currency from the right row	planstep.size	Fixed here
AWS RI exchange max_payment_due_usd vs quote currency	go ExecuteExchange (go#203)	Covered by go#203. Open PR #1212 (fix/issue-521) maps ErrQuoteNotUSD to 422. Not duplicated here
Azure RI exchange MaxPurchaseAmount vs exchange currency	checkAzureExecuteConstraints	Already fail-closed on main
maxPayment, _ := maxRat.Float64() drops the exactness flag	handler_ri_exchange.go	Left alone. The file is touched by open PRs #1212, #1116, #1191, #1243, #1246, #1172, #1175
firstNonEmptyCurrency defaults reshape output to "USD"	handler_ri_exchange.go	Deferred for the same reason. #1246 (fix/issue-1206) edits the function that calls it
Plan max_step_commitment vs step total (auto-purchase, and the email-token approver with no approve verb)	purchase.CheckStepCommitmentCap, requirePlanStepCap	Not fixed. Needs an owner decision. Every auto-purchase step must have this cap, and the pinned Azure provider never sets CommitmentCurrency. Failing closed here would stop every Azure auto-purchase plan until the go side populates Azure currency. The edit is small (about 20 lines in step_cap.go, separate from #1245's hunk in the same file)
Azure revoke refund-divergence guard	handler_purchases_revoke.go	Its own issue (cli#1555). checkConfirmedRefund already refuses a currency mismatch
ri_exchange_history.payment_due has no currency column	daily-cap ledger	Out of scope per the issue, until a second currency is supported
Azure recommendations carry no currency	pinned providers/azure 3def3f89	Go side. Until a go bump populates it, Azure recs are "unknown" (see below)

Behavior change to review

• Existing stored recommendations have no currency until the next collection. Until then, a user or API key with a spend cap is refused on every purchase. Users and keys without a cap, and the admin key, are not affected. The 403 tells the caller to refresh recommendations. AWS and GCP recs carry a currency after one refresh.
• Azure purchases under a capped grant stay refused until the go Azure parsers set CommitmentCurrency. That is fail-closed by design: the cap cannot be checked against an amount of unknown currency.
• Pending executions created before deploy also carry no currency. A capped approve-any/approve-own approver is refused on them. They can be approved by an uncapped approver or the admin key, or cancelled and resubmitted after a refresh.

Verification

All evidence below is unit tests against mocks/fixtures, plus real-Postgres integration tests on the shared testcontainers Postgres. No real cloud API was called and nothing was purchased. Tests ran with AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true.

New tests:

• internal/api/purchase_currency_test.go (unit; the mock answers with the real auth.PermissionsAllowForConstraintSets):
  • TestEnforcePurchaseConstraints_NonUSDUnderCapRefused: 900 EUR / JPY / empty / whitespace against a 1,000 USD cap, for execute, execute-any, approve-any and approve-own.
  • ..._MixedBatchRefused
  • ..._USDStillComparedAgainstCap: USD, usd, USD. Over the cap is still refused.
  • ..._NonUSDWithoutCapAllowed
  • ..._NonUSDOtherDimensionKeepsItsError
  • ..._NonUSDBackendErrorPropagates: exactly one auth call.
  • TestHandler_executePurchase_NonUSDStoredPriceUnderCapRefused: the full web execute path with a stored EUR row and a request claiming USD. Nothing is saved.
• internal/planstep/resolve_test.go: TestResolveTakesCurrencyFromStoredRow.
• internal/scheduler/scheduler_test.go: TestScheduler_ConvertRecommendations_CommitmentCurrency.
• internal/api/combined_plan_purchase_integration_test.go (real Postgres): TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap. A 2,400 EUR stored recommendation goes through UpsertRecommendations, then the scheduler's plan-step attach (SendUpcomingPurchaseNotifications), then the purchase_executions row. The test asserts EUR round-trips to the execution row. Then POST /api/purchases/approve/{id} with an approve-any cap of 2,400 and of 1,000,000 must be 403 naming EUR, with nothing bought. With no cap it must be 200 and complete.

Existing fixtures that model USD recs under a cap now say CommitmentCurrency: "USD" (they had no currency, which now means unknown). fanoutRecs() and the combined-plan fixture default to USD, so the existing claimed-row and combined-plan integration tests still exercise the USD cap. No assertion was weakened.

Fail before. I put back origin/main's handler_purchases.go, planstep/resolve.go and scheduler/scheduler.go and kept the new tests:

• Unit: TestEnforcePurchaseConstraints_NonUSDUnderCapRefused, ..._MixedBatchRefused, TestHandler_executePurchase_NonUSDStoredPriceUnderCapRefused, TestResolveTakesCurrencyFromStoredRow and TestScheduler_ConvertRecommendations_CommitmentCurrency all fail.
• Real Postgres: TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap fails with expected: 403, actual: 200 and body {"status":"completed"}. The 2,400 EUR step was approved under the 2,400 USD cap and bought: f.service.recorded() is non-empty.

Pass after. Commands:

go build ./... && go vet ./... && go vet -tags integration ./...
go test ./internal/api/ -count=1          # ok
go test ./internal/planstep/ -count=1     # ok
go test ./internal/scheduler/ -count=1    # ok
go test ./internal/config/ -count=1       # ok
go test ./internal/mocks/ -count=1        # ok
go test -tags integration -count=1 -timeout 60m -run 'TestCombinedPlanPurchase_|TestClaimedRowCheck_Postgres' ./internal/api/   # ok
golangci-lint v2.10.1 run --allow-parallel-runners [--build-tags integration] ./internal/api/ ./internal/planstep/ ./internal/scheduler/ ./internal/config/   # 0 issues (both)
gocyclo -over 10 -ignore "_test\.go" <changed non-test files>   # silent
bash scripts/gosec-hook.sh <changed non-test .go files>        # clean
gofmt -l internal/                                              # clean

The machine was heavily loaded (load average about 24, about 50 containers from parallel suites). Two integration runs hit testcontainers start-up flakes: a reaper container in "removing" state, and 90-second subtests. Each test passed when re-run. The full run of the targeted set passed once with all green. I did not run whole integration packages or git-secrets here; the combined-tree run covers them.

Combined-tree verification. This branch was tested together with the other queued branches on a local, never-pushed tree: queue/platform @ 936996ad = origin/main a14dc8f2 plus these heads, merged in this order:

Branch	Tested head
fix/issue-337	ff3420c
fix/issue-169	7d75eb5
fix/issue-342	66b221f
fix/issue-310	5e11c21
fix/issue-326	5f0ea59
fix/issue-243	365e959
fix/issue-343	6c94036
fix/issue-312	d2848a8
fix/issue-316	acd60dd
fix/issue-339	75ea9b9
fix/issue-339-commitment-type	73bdb19
fix/issue-353	5d25fcd
fix/issue-313	3156bc4
fix/issue-357	53d9e58
fix/issue-368	0ba727d
fix/issue-419	61648c9
fix/issue-111	b04c372
fix/issue-686	0ad90b7
fix/issue-674	793095d
fix/issue-1055	4ec96f1
fix/issue-559	dfa9525
fix/issue-558	034eed4
fix/issue-874	1720539
fix/issue-666	1e120da
fix/issue-668	fb26345
fix/issue-568	ce04173
fix/issue-311	e54f250
fix/issue-177	0cbb88a
fix/issue-151	c21377c
fix/issue-166	41fb77b
fix/issue-27	2d67622
fix/issue-323	69288ae
fix/issue-59	36463e8
fix/issue-43	35e4069
fix/issue-158	6f76f8a
fix/issue-104	bb00491
fix/issue-55	971ef1b
fix/issue-361	89ac220
fix/issue-120	b458719
fix/issue-36	42bac6e
fix/issue-525	57c97dd
fix/issue-712	e5bcda0
fix/issue-72	6cc63ed

fix/issue-72 and fix/issue-312 conflict on one line in internal/api/handler_dashboard.go (both change the calculateCommitmentMetrics call). The tree used #72's side with #312's validated provider variable; whichever PR merges second takes that same resolution.

Linux, Go 1.26.9, AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true; Docker Postgres via testcontainers:

• Passed at 936996ad: go build ./..., go vet ./..., go vet -tags integration ./... and the full go test -race -short -count=1 ./....
• Static checks at 936996ad: golangci-lint v2.10.1 found 0 issues on every changed package, with and without --build-tags integration. tests/e2e is a separate module, so it was vetted under its own e2e tag. gocyclo -over 10 is silent on the changed non-test files.
• Integration tests, every changed package, one package at a time (-tags integration -count=1, 60-minute local timeout because the VM was shared):
  • At 936996ad, these pass: internal/server, internal/credentials, internal/scheduler, internal/database/postgres/migrations, internal/purchase and internal/api.
  • internal/config passes except TestPostgresStoreDB_ResolveStaleRIExchange_ValidatesCloudCheck, which fails the same way on unmodified main (fixed by fix(config): compare resolve checked_at at the database's microsecond precision #1252).
  • These were run on the first build of this tree (26795376, same branches at earlier heads): internal/analytics, internal/auth, internal/commitmentopts, internal/database and cmd/lambda/clear-rate-limit all pass. The later fixes don't touch those packages.
• What the combined run caught, each fixed on its own branch before this PR opened:
  • a compile break between fix/issue-104's test and fix/issue-326's httpToLambdaRequest signature change;
  • fix/issue-316 rejecting legacy-keyed plans;
  • fix/issue-120 versus main's global-filter test.
• Secrets: git-secrets, using the repo's scripts/setup-git-secrets.sh patterns in a fresh repo with an isolated HOME, found nothing in the changed files, and a planted fake key was flagged. scripts/test-git-secrets-allowlist.sh: 137 PASS, 0 FAIL.
• Nothing was applied to any cloud.

Not in scope

• The plan max_step_commitment boundary and the two handler_ri_exchange.go items. See the table for why each was deferred.
• Populating Azure CommitmentCurrency. That belongs to cloud-commitments-go.
• A Money type, or a currency field on the caps. The issue rules both out.

Frontend follow-up for the UI owner

No frontend files are changed. The recommendations API now returns commitment_currency on each rec, and the field is omitted when unknown. Two UI changes would help:

• The recommendations and purchase screens hard-code $. They could show the currency, or flag a rec with an unknown or non-USD currency.
• They could warn that a capped user's purchase of such a rec will be refused.

The new 403 is a plain {"error": ...} message, so the existing error toast already shows it.

Labels

A maintainer, please mirror the issue's triage labels: priority/p2, severity/high, urgency/this-quarter, impact/few, effort/l, type/bug, triaged.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}