[IAmJSD]

Stacked on #1269 (fix/issue-339). This branch starts from #1269's first commit, so until #1269 merges the diff also shows that commit. Review only the last commit, 73bdb19d. It is split out because it needs a migration, while #1269 doesn't.

Refs #339

Root cause (audit finding A06-019)

commitmentTypeFor (internal/analytics) only recognised a service named exactly "SavingsPlans", which purchase_history never stores. So every snapshot was labelled "RI", including AWS Savings Plans (savingsplans / savings-plans-<type>) and GCP committed-use discounts. The audit only mentioned GCP; AWS Savings Plans were mislabelled too.

Fix

• New internal/analytics/commitment_type.go: derives the type from (provider, service) using the pkg/common CommitmentType vocabulary. The collector uses it, and the old literal match in postgres_analytics.go is removed.
• Migration 000141 (savings_snapshots_commitment_type_vocabulary): widens the savings_snapshots CHECK to the new vocabulary and relabels existing rows. The CHECK still accepts the legacy RI and SavingsPlan literals, so an old replica can keep writing during a rolling deploy.
• Down migration: restores the old CHECK. Rows are relabelled back, so a rollback turns GCP and Savings Plans rows into RI again.

Migration order

Migration number: 000141 (renumbered from 000145 on 2026-10-26). main is at 000139. The reviewed, ready PRs take 000140-000145 and merge in this order: #1240 (000140) → #1302 (000141) → #1268 (000142) → #1287 (000143) → #1289 (000144) → #1116 (000145). golang-migrate skips a version below the database's current one, so merge this after #1240 and before #1268. #1239 (was 000140-000141), #1241 (was 000143) and #1253 (was 000144) are held on owner decisions and will be renumbered to start at 000146 when decided.

Verification

Branch evidence: unit tests (collector_test.go, postgres_analytics_test.go, mock test updates), a real-Postgres test (commitment_type_db_test.go) and a migration test (000141_..._test.go) covering the relabel and the CHECK.

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.

Review manually

• Vocabulary: whether pkg/common's CommitmentType labels are the right ones to store.
• Legacy literals: keeping RI and SavingsPlan in the CHECK during the rollout, and when to remove them in a later migration.
• Rollback: rolling back relabels GCP rows as RI.

Labels to mirror from #339: triaged, priority/p3, severity/low, urgency/eventually, impact/few, effort/m, type/bug.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 10 billable files and costs up to $2.50.}

Or wait 59 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: LeanerCloud/cloud-commitments-platform
• Branch: main
• File: .coderabbit.yaml
• Commit: 2a11540
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 56860eda-3502-450e-8667-eb4786562af1

Commits

Reviewing files that changed from the base of the PR and between 2a11540 and 6b229af.

Files selected for processing: 10

• internal/analytics/collector.go
• internal/analytics/collector_test.go
• internal/analytics/commitment_type.go
• internal/analytics/commitment_type_db_test.go
• internal/analytics/postgres_analytics.go
• internal/analytics/postgres_analytics_mock_test.go
• internal/analytics/postgres_analytics_test.go
• internal/database/postgres/migrations/000141_savings_snapshots_commitment_type_vocabulary.down.sql
• internal/database/postgres/migrations/000141_savings_snapshots_commitment_type_vocabulary.up.sql
• internal/database/postgres/migrations/000141_savings_snapshots_commitment_type_vocabulary_test.go

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

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

[IAmJSD]

CI fix pushed. New head: ba15e4ae.

Root cause. The unit test TestNoUnfailableMockAssertions (internal/mocks) could not resolve the receiver type of two assertions this branch inherited from #1269's older head 28b9a411:

• internal/purchase/empty_selection_notify_test.go:105: mockEmail came from allowFailedNotification(new(MockEmailSender)).
• internal/purchase/approvals_test.go:307: sender came from the multi-value newApproveManager(t).

The guard is syntactic, so it reports a call result it cannot type as unchecked.

Fix. #1269 (fix/issue-339) already fixed both sites in 75ea9b92:

• In empty_selection_notify_test.go it declares mockEmail := new(MockEmailSender) and then calls allowFailedNotification(mockEmail). The assertion is unchanged.
• In approvals_test.go the no-confirmation check now relies on having no SendPurchaseConfirmation expectation registered, so any send fails the test.

Because this PR is stacked on #1269, I merged #1269's current head 63adf280 into this branch instead of writing a second, diverging fix. That keeps the two branches identical in those files. #1269 itself passes the guard, so it needed no change.

Other changes: I merged origin/main twice as plain merges with no conflicts. The 000145 migration number is unchanged.

Checks run locally on the new head:

• go build ./..., go vet ./..., go vet -tags integration ./... and the tests/e2e vet all pass.
• golangci-lint v2.10.1 reports 0 issues on internal/analytics, internal/database/postgres/migrations, internal/purchase and internal/server, both with and without --build-tags integration.
• gocyclo -over 10 on the changed non-test files reports nothing.
• go test -race -short passes on all four packages, and TestNoUnfailableMockAssertions passes.
• go test -race -tags integration:
  • internal/purchase passes.
  • internal/server passes.
  • internal/database/postgres/migrations passes, including TestMigration_SavingsSnapshotsCommitmentTypeVocabulary.
  • internal/analytics passes.
  • On this heavily loaded host, some tests first failed only because their Postgres container did not start within its 30s wait. I reran those tests until they passed.
• The secrets scan of the changed files prints "clean; planted key flagged".
• bash scripts/test-git-secrets-allowlist.sh: 137 PASS, 0 FAIL.

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: REQUEST_CHANGES ba15e4aed919545900b4668fa53fa80b94afbc63

Blocking:

• internal/analytics/collector_test.go:240 (after merging with current main): undefined: common. Main's test(analytics): fold the hand-rolled ConfigStore mock onto mocks.MockConfigStore #1254 (7749401a, merged after this branch last took main at ba15e4ae) folded the hand-rolled config-store mock onto mocks.MockConfigStore, and that change removed the cloud-commitments-go/pkg/common import from this file. git merge-tree still reports a textually clean merge, so nothing flags it, but the new assertion string(common.CommitmentReservedInstance) no longer compiles. The PR shows mergeStateStatus: CLEAN with a green CI Success from the older merge ref, so merging now would break go test/go vet for internal/analytics on main. Fix: git merge origin/main and restore the import (or compare against the literal). I re-added the import in my scratch tree and everything below passes.

Non-blocking:

• Migration ordering: no test or CI check stops a lower-numbered migration from landing after a higher one. If 000145 is applied before fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239/perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240/feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241/fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253 (000140-000144) merge, migrate up on that database will never run them. The body says to merge after fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253, and merge order is the only safeguard, so please hold this PR until 000140-000144 are in.
• 000145.up.sql: the relabel UPDATE rewrites every savings_snapshots row while holding ACCESS EXCLUSIVE, and ADD CONSTRAINT ... CHECK rescans every partition under the same lock. The table is one row per bucket per collection, so this should be seconds. On a large tenant it blocks dashboard reads for the duration. NOT VALID + VALIDATE would shorten the exclusive window if that ever matters.
• Rows written by an old replica after the migration keep RI/SavingsPlan forever, because nothing re-runs the relabel. monthly_savings_summary doesn't group by commitment_type (000078), so totals are unaffected, and only the per-row label is off for that short window. A later migration that drops the legacy literals from the CHECK has to relabel them first anyway.
• Go and SQL precedence differ in one place. SQL maps commitment_type='SavingsPlan' before checking provider='gcp', while Go puts GCP first. The two only disagree for a GCP row with the legacy SavingsPlan label, which the old mapper couldn't produce.

Attacked:

• I reviewed the effective change, meaning the merge of the head into current main (eb9e480). fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 is squash-merged, so only the 10 analytics/migration files remain.
• Readers of commitment_type: only the analytics store reads it back. The frontend has no reader (the commitment_type hits are Archera DTOs). No materialized view groups by it. The PK is (id, timestamp), so the relabel can't collide. isSavingsPlanService matches common.IsSavingsPlan's slugs plus savings-plans, and the SQL IN (...) list is the same set.
• Fail-before:
  • The old commitmentTypeFor/validateCommitmentType swapped in makes TestCollectorCollect (2 subtests), TestCommitmentTypeLogic and TestValidateCommitmentType fail, in both unit and integration builds.
  • An empty 000145 up migration makes TestMigration_SavingsSnapshotsCommitmentTypeVocabulary fail. That test also covers down, then up again, in both a named partition and the default partition.
• Checks run on the merged tree with the import restored:
  • go build ./... and go vet (with and without -tags integration) on internal/analytics and the migrations package
  • go test -race -short -count=1 on both packages
  • go test -race -tags integration -count=1 ./internal/analytics/
  • the 000145 test plus the up/down/idempotency tests in the migrations package
  • golangci-lint, with and without the integration tag: 0 issues
  • gocyclo: silent

Body-stale:

• "Stacked on fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 ... until fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 merges the diff also shows that commit": fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 is merged.
• "after the open chain 000135–000143 (fix(auth): bind group account scope entries to account IDs #1116 → … → feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241)": fix(auth): bind group account scope entries to account IDs #1116 now holds 000149, and main has no 000135. The open migrations below this one are 000140-000144 (fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239, perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240, feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241, fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253).
• Refs #339: fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 fixed A05-015 and A06-009, and this PR fixes A06-019, the last item. With both merged, this PR could use Closes #339, or someone should close the issue by hand.

_{Reviewer: rB20. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[IAmJSD]

Addressed the review at ba15e4ae: merged origin/main and restored the pkg/common import that #1254 removed from collector_test.go (this branch's new assertion uses it). New head 337d25e4. Build, vet (both tag sets), analytics race unit and integration tests and golangci-lint pass; secrets scan clean. Its migration 000145 still has to merge after 000140-000144.

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE 337d25e4ecf123bb06b7af42507f004dc053198f

Blocking:

• none

Non-blocking:

• Rolling deploy. 000145_..._vocabulary.up.sql relabels only the rows that exist at migration time. Any RI or SavingsPlan row that an old replica writes after the migration and before it is replaced keeps the legacy label for good. Readers are unaffected today: no query filters or groups on commitment_type (QueryByProvider and the monthly summary group by provider and service only). A later migration that drops the legacy literals from the CHECK should relabel those stragglers first. That's worth a line in the follow-up issue.
• Lock time on large deployments. The UPDATE rewrites every existing snapshot row, across all partitions, inside the same transaction as the ACCESS EXCLUSIVE constraint swap. On a big deployment, collector writes block for the length of the rewrite. That's fine at current sizes, but it's something to know when this deploys.
• API change, owner call. The commitment_type in snapshot JSON changes from RI/SavingsPlan to the pkg/common values (reserved-instance, savings-plan, committed-use). The frontend never reads it, and neither does the MCP or CLI main. Any external API consumer would see the new strings.

Attacked:

• Consistency. Compared the Go mapper with the SQL relabel: GCP becomes committed-use, and every common.IsSavingsPlan slug, plus savingsplans and the pre-Do not add the CodeRabbit status to required checks: it reports success while throttled #85 savings-plans, becomes savings-plan. The SQL list matches the five ServiceSavingsPlans* constants in pkg@541e05e5. allowedCommitmentTypes mirrors the new CHECK exactly.
• Keys. The PK is (id, timestamp), so relabelling can't collide. The migration number is 000145, as reserved for this PR, and main is at 000139.
• Commands. go build ./.... go vet, with and without -tags integration, on analytics and migrations. go test -race -short -count=1 on both (ok). go test -race -tags integration -count=1 ./internal/analytics/ (ok). The full ./internal/database/postgres/migrations/ integration package (ok, 218s, including the new up/down/up test across a monthly and the default partition). golangci-lint v2.10.1, with and without the integration tag (0 issues). gocyclo (silent).
• Fail-before, in a separate scratch tree. I restored the merge-base collector and validator, behind a shim with the new signature. TestCollectorCollect, TestCommitmentTypeLogic and TestValidateCommitmentType fail. TestCollector_GCPCommittedUse_DB fails with actual: {"aws/ec2":"RI","aws/savingsplans":"RI","gcp/compute":"RI"}. All pass on the head.

Body-stale:

• "Stacked on fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 … the diff also shows that commit. Review only the last commit": fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 has merged, so the three-dot diff now contains only this change.
• "000145 is after the open chain 000135–000143 (fix(auth): bind group account scope entries to account IDs #1116 → … → feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241)": main now has 000135 to 000139.
• Refs #339: fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 (merged) covered the other two findings in chore(purchase/server/analytics): low correctness findings from the 2026-09-02 audit [platform part] #339, and this PR is the last one. Unless something else remains, this can say Closes #339.

_{Reviewer: rB23. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[cristim]

Independent review 1 (cold, fresh context):

VERDICT: APPROVE 337d25e
PR #1302 is OPEN. The diff against origin/main is only the analytics and 000145 files, because #1269 has merged.

Findings:

• low internal/database/postgres/migrations/000145_savings_snapshots_commitment_type_vocabulary.up.sql:17-39 - The DROP CONSTRAINT takes ACCESS EXCLUSIVE on the parent and every partition and holds it through a full-table UPDATE (every existing row is legacy, so every row is rewritten) plus the CHECK validation scan, all in one transaction. The comment talks only about concurrent inserts, but analytics SELECTs and the matview refresh also block for the whole migration. Failure scenario: on a large table, dashboard analytics hang for the duration. Mitigating factor: the collector runs daily (terraform default rate(1 day)) with 24-month retention, so real tables are buckets x ~730 rows and the lock should last seconds. Not blocking. Worth one sentence in the comment.
• nit internal/analytics/commitment_type.go:33-43 - Unmapped pairs are not rejected. Any non-GCP provider/service that is not a Savings Plans slug becomes "reserved-instance", including an empty or unknown provider and the dash-free per-type spellings that purchase/execution.go:1319-1325 accepts ("savingsplans-compute" etc.). Today purchase_history.service is rec.Service (purchase/execution.go:1005), which comes from the canonical collector slugs, and nothing grep finds produces "savingsplans-". So nothing is mislabeled today, but a new SP alias would be mislabeled with no error. The SQL backfill (up.sql:31-36) has the same default, so the two are consistent.
• nit up.sql:12-15 - Rows that an old-binary replica writes after the migration keep "RI" or "SavingsPlan" for good, because the backfill runs once. The follow-up that drops the legacy literals from the CHECK has to repeat the relabel. No reader filters on commitment_type (grep of internal/, cmd/, frontend/src and the matview SQL), so nothing user-visible changes.
• nit down.sql:10-15 - The down migration is not an exact inverse. "savingsplans" and "savings-plans-*" rows go to "SavingsPlan", but the pre-fix code wrote "RI" for them, since it only wrote "SavingsPlan" for the literal "SavingsPlans". The result still passes the old CHECK and nothing reads the value, so this is harmless. The comment already says the down is lossy.
• merge-order: migration 000145 is above origin/main's highest (000139) and no other open PR uses 145 (others: fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239 140/141, perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240 142, feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241 143, fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253 144, fix(config/db): seed-group rollbacks, partition-safe 000027 dedupe, fail-closed plan providers, revocation_in_flight clear #1268 146, fix(analytics): keep unknown usage and commitment unknown in the savings rollups #1287 147, feat(marketplace): poll RI Marketplace listings and record proceeds and AWS fee (backend slice of #27) #1289 148, fix(auth): bind group account scope entries to account IDs #1116 149). If fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253 merges after this PR, golang-migrate skips 000144 on DBs already at 145. Merge fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253 first, or renumber.

Attacked:

• Provider/service coverage. Go and SQL give the same answers:
  • Any provider with savingsplans, savings-plans, savings-plans-{compute,ec2instance,sagemaker,database}, case-insensitive (ToLower plus common.IsSavingsPlan, matching the SQL lower(service) IN list): savings-plan.
  • gcp/any (EqualFold, matching lower(provider)): committed-use.
  • aws ec2/rds/elasticache/opensearch/redshift/memorydb and azure compute/relational-db/etc.: reserved-instance.
  • Azure Savings Plans use service "savingsplans" (commitmentopts/probe_azure.go:15) and get savings-plan.
  • The legacy "SavingsPlans" row is handled in both Go and SQL.
  • Nothing emits reserved-capacity. It is in the allow-list only to mirror the CHECK.
• Duplication: there is no other provider/service-to-CommitmentType mapper in internal/. The old validateCommitmentType was moved, not copied.
• Blast radius: raw snapshot commitment_type is not exposed in openapi.yaml or the frontend. QueryByProvider and the monthly matview group by provider/service, not commitment_type. There is no unique index on the bucket grain, so the relabel cannot collide (PK is (id, timestamp)).
• Partitions: every partition is created with PARTITION OF (000003, 000132), and none comes from an ATTACH. So DROP/ADD on the parent covers every child; the test checks a named partition and the default partition.
• Tests run in my scratch copy of the head:
  • go vet and go test -race ./internal/analytics: 186 pass.
  • -tags integration ./internal/database/postgres/migrations: ok (52s).
  • -tags integration ./internal/analytics, including commitment_type_db_test: ok.
• Mutation probes. Each was reverted afterwards; cmp confirmed the files are byte-identical to the archive.
  • Remove || s == "savings-plans": killed by TestCommitmentTypeLogic.
  • Remove ToLower: killed by TestCommitmentTypeLogic.
  • GCP case set to false: killed.
  • EqualFold changed to ==: killed.
  • Drop CUD from the allow-list: killed.
  • Remove 'savings-plans-compute' from the up.sql IN list: killed (expected savings-plan, got reserved-instance).
  • down.sql relabel WHERE set to false: killed (the down migration fails on the restored CHECK with 23514 on savings_snapshots_default).

[cristim]

Independent review 2 (claude-fleet, cold): REQUEST_CHANGES at 337d25e

blocking

• internal/analytics/commitment_type.go:40-41 and 000145...up.sql:37 send every pair they don't recognise to reserved-instance. That covers an empty or unknown provider, any AWS or Azure service the code doesn't list, and the dash-free "savingsplans-" aliases that internal/purchase/execution.go:1319-1325 accepts as forward-compat. This conflicts with the unknown-stays-unknown rule (fix(analytics): keep unknown usage and commitment unknown in the savings rollups #1287). No test pins unknown handling, and no probe can kill this default. Today nothing reachable is mislabelled: purchase_history.service comes only from execution.go:1005 (rec.Service), whose values come from provider collectors, and the provider tables below match. The risk is latent: a future service or alias gets a definite wrong label with no signal. Fix: add an explicit RI set (aws: ec2/compute, rds/relational-db, elasticache/cache, opensearch/search, redshift/data-warehouse, memorydb; azure: compute, relational-db, cache, search, nosql). Skip and count, or error on, anything else, the same way Term<=0 is skipped at collector.go:149-152. Mirror that in the SQL ELSE. Add a test for an unknown provider and an unknown service.

non-blocking

• 000145_..._test.go legacy rows (around line 70) cover only savingsplans, savings-plans-compute and SavingsPlans. Removing 'savings-plans-sagemaker' or 'savings-plans' from up.sql:33-35 survives, and so does changing lower(provider) to provider. Add a row for each of the six SP slugs and one 'GCP' row, so the SQL list is pinned the way TestCommitmentTypeLogic pins the Go one.
• Duplication: commitment_type.go:49-51 is a third copy of the SP slug family, after common.IsSavingsPlan and mapSavingsPlansSlug (execution.go:1314). analytics can't import purchase, so it is acceptable, but a cross-reference comment would help. config.CanonicalSuppressionService (origin/main types.go:781) canonicalises service slugs, not commitment types, so there is nothing to reuse for the label itself.
• up.sql:17 says "one transaction (golang-migrate)". Main's docs(db): clarify migration transaction and recovery comments #1281 rewrote migration_transactional_test.go: the file is atomic as one simple-protocol Query, and golang-migrate adds no BEGIN. The comment is stale but the behaviour is right.
• Ordering: 000145 is above main's top (000139). Open migrations are 000140/141 (fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239), 000142 (perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240), 000143 (feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241), 000144 (fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253, as other reviewers reported; no local ref), 000146 (fix(config/db): seed-group rollbacks, partition-safe 000027 dedupe, fail-closed plan providers, revocation_in_flight clear #1268) and 000147 (fix(analytics): keep unknown usage and commitment unknown in the savings rollups #1287). No other PR uses 145. golang-migrate never applies a version below the current one, so merge fix(recommendations): key stored recs, rec ID and purchase identity on RDS az_config (#408) #1239, perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240, feat(plans): settle a failed-with-submission row so a managed plan can be deleted #1241 and fix(db): contract the canceled rename: normalize, narrow the status CHECKs, stop using cancelled_by #1253 first, or renumber.
• Lock: the parent DROP/ADD CONSTRAINT takes ACCESS EXCLUSIVE on every partition, held through the full UPDATE and the validation scan. On main, migrations run on the request-time ensureDB path. Tables are small (daily snapshots, 24-month retention), so this should be seconds.
• Rows an old replica writes after the migration keep RI/SavingsPlan for good, a GCP row included. The follow-up that drops the legacy literals must relabel them first.

label table (provider / slug / label / source of truth / test)

• aws / ec2, compute, rds, relational-db, elasticache, cache, opensearch, search, redshift, data-warehouse, memorydb / reserved-instance / providers/aws services/*/client.go (ec2:108, rds:104, elasticache:98, opensearch:112, redshift:91, memorydb:92), parser_ri.go:64 / TestCommitmentTypeLogic covers ec2, rds, elasticache, opensearch only. Canonical slugs, redshift and memorydb have no test, because the default arm catches them.
• aws / savingsplans, savings-plans-{compute,ec2instance,sagemaker,database} / savings-plan / parser_sp.go:260,319-331, pkg common/types.go:118-129,159 / Go: all; SQL: only savingsplans and -compute.
• aws / savings-plans (pre-Do not add the CodeRabbit status to required checks: it reports success while throttled #85), SavingsPlans / savings-plan / execution.go:1315, the old mapper / Go yes; SQL only SavingsPlans.
• aws / savingsplans- (dash-free) / reserved-instance (wrong) / execution.go:1319 / none.
• azure / compute, relational-db, cache, search, nosql / reserved-instance / azure services/*/client.go (database:312, cache:279, search:200, cosmosdb:280, compute:789) / compute only.
• azure / savingsplans / savings-plan / azure savingsplans/client.go:266-267, recommendations.go:676 / indirect, through the aws case.
• gcp / compute, relational-db, cache / committed-use / gcp computeengine:592, cloudsql:562, memorystore:530 / Go yes (including GCP/cloudsql); SQL lowercase only.
• unknown or empty / reserved-instance / none / none (blocking).

migration analysis

• The up migration is idempotent: DROP IF EXISTS, the UPDATE only touches legacy rows, then ADD. The legacy backfill is correct for every reachable slug, and the PK (id, timestamp) means no collisions.
• The down migration is deliberately lossy: everything except savings-plan becomes RI, which passes the old CHECK. Up, down, up round-trips (tested).
• All partitions are created with PARTITION OF, and the test covers a named partition and the default one.

consumer table

• analytics collector.go:161,225 / writes the label / the aggKey includes it, and it is still a pure function of provider and service / OK.
• postgres_analytics.go:98,172 / validateCommitmentType mirrors the CHECK / OK.
• QuerySavings (postgres_analytics.go:211) / returns the label / no production caller (api/types.go:101 is only an interface) / OK.
• Matviews (000067, 000074, 000078) and fix(analytics): keep unknown usage and commitment unknown in the savings rollups #1287's 000147 / group by provider and service only, never commitment_type / OK.
• api QueryBreakdown dimensions (analytics_postgres.go:65-76) / commitment_type is not a dimension / OK.
• frontend, openapi / the only commitment_type fields are Archera DTOs (types.ts:1097,1112; openapi.yaml:5547,5566) / not affected.

probes (head export; each file restored with cp and checked with cmp, and the three probed files were then cmp'd against git show 337d25e)

• Go: drop "savings-plans" KILLED; mislabel savings-plans-database KILLED; default changed to reserved-capacity KILLED; GCP case set to false KILLED; legacy RI dropped from the allow-list KILLED.
• SQL: skip backfill (WHERE false) KILLED; drop the provider='gcp' arm KILLED; down maps SP to RI KILLED; drop 'savings-plans-sagemaker' SURVIVED; drop 'savings-plans' SURVIVED; lower(provider) changed to provider SURVIVED.
• default unknown to RI: this is the shipped behaviour, so no probe applies. Reported as blocking above.

fail-before: I copied head's tests into base, with a shim for the new commitmentTypeFor(provider, service) signature. TestCollectorCollect (2 subtests), TestCommitmentTypeLogic and TestValidateCommitmentType FAIL. TestCollector_GCPCommittedUse_DB FAILS (actual: all "RI"). The 000145 test FAILS at MigrateToVersion(145).

history: the first-parent chain is 337d25e (adds only the common import, needed and correct) on 6513cf5, ba15e4a, 55a2753 and ae4f340 (merges). --remerge-diff is empty for all four merges, so there were no hand resolutions.

commands (no cloud creds, GOTOOLCHAIN=go1.26.10)

• merge-tree --write-tree origin/main (bee0627, 20 commits past the merge-base; main changed migrate.go) and pr/1302: clean, tree bbcf9a40. I exported it to ccp1302.merged.
• On head and merged: go build ./... ok; go vet, with and without -tags integration, on analytics and migrations ok; gofmt clean; go test -short on both packages ok.
• golangci-lint 2.11.4, with and without --build-tags integration, on the merged tree: 0 issues.
• Under the heavy lock, merged tree: go test -tags integration ./internal/analytics/ ok (7s), ./internal/database/postgres/migrations/ ok (54s).

Reviewed by an independent agent with no author context (second reviewer). Review only: nothing was pushed, and the GitHub review state is unchanged.

[cristim]

On the two reviews at 337d25e: our first review flagged the same default as a nit (an unknown provider or service, and the dash-free savingsplans-<type> aliases, all become reserved-instance). I'm upgrading it to agree with the second review's REQUEST_CHANGES. A silent default breaks the "unknown stays unknown" rule #1287 adds for these same snapshots, and no test fails if it regresses.

@IAmJSD the fix the second review suggests is enough:

• list the reserved-instance pairs explicitly per provider;
• skip and count anything else, or error, the same way the Term<=0 skip works;
• mirror that in the SQL ELSE;
• add tests for an unknown provider and an unknown service.

Merge order is unchanged: 000145 lands after 000140 to 000144.

[IAmJSD]

Renumbered migration 000145 -> 000141 so it can merge ahead of PRs held on owner decisions (#1239, #1241, #1253, which will take the next free numbers when decided). Rename only; SQL unchanged.

New head: 6b229aff. The branch first merged origin/main (2a115407); then one commit renames the up/down/test files and updates the test's version constant and the comments that name the number (including the self-referencing header comments in the .sql files; no statement changed).

Note: #1269, which this PR was stacked on, has merged, so the diff now shows only this PR's own change.

Merge order for the ready PRs: #1240 (000140) -> #1302 (000141) -> #1268 (000142) -> #1287 (000143) -> #1289 (000144) -> #1116 (000145). The PR body's migration-number paragraph is updated to match.

Checks on this head (local): build, vet (plain, integration, e2e), golangci-lint v2.10.1 with and without the integration tag and gocyclo -over 10 on the changed packages, go test -race -short and go test -race -tags integration on the changed packages (including the migrations package's up/down round trip and number guards), secrets scan and git-secrets allowlist test. The six renumbered branches were also merged onto origin/main in that order in one scratch tree, and go test -race -tags integration ./internal/database/postgres/migrations/ passed there, so the chain applies up and down cleanly together.

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE 6b229affd6c77b7621b7e42919d7db22ae360fa7

Blocking:

• none

Non-blocking:

• 000141 up runs UPDATE savings_snapshots ... WHERE commitment_type IN ('RI','SavingsPlan') across the whole partitioned table. That's effectively every historical row, followed by a validating ADD CONSTRAINT, all under ACCESS EXCLUSIVE. On a large snapshot history, dashboard reads and the collector block for the full rewrite. The body's "Review manually" section acknowledges the lock. The only other note is that the cost scales with history size.
• Mixed vocabulary after a rolling deploy: an old replica that writes after the migration leaves RI / SavingsPlan rows that nothing relabels later. The follow-up migration that drops the legacy literals (body, "Review manually") will need to repeat the relabel UPDATE before it tightens the CHECK. Nothing reads commitment_type by literal today (I grepped Go, SQL and frontend; the rollup views don't group by it, and QuerySavings has no API caller), so there's no functional impact now.
• Dash-free per-type slugs (savingsplans-compute etc., which fix(config): canonicalise dash-free Savings Plans spellings in suppressions #1456 shows a direct API client can store in purchase_history) are labelled reserved-instance by both isSavingsPlanService and the SQL relabel list. Go and SQL at least agree. Adding them would be a one-line follow-up if fix(config): canonicalise dash-free Savings Plans spellings in suppressions #1456 lands.
• With fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 merged, this PR completes chore(purchase/server/analytics): low correctness findings from the 2026-09-02 audit [platform part] #339's third item. chore(purchase/server/analytics): low correctness findings from the 2026-09-02 audit [platform part] #339 can probably be closed after merge, but this PR correctly says Refs.

Attacked:

• Checked that the Go and SQL vocabularies agree. common.IsSavingsPlan (pinned pkg) accepts savings-plans, the four savings-plans-* slugs and savingsplans, and the PR adds savings-plans. The SQL relabel list holds the same six, lowercased, with GCP checked first in both. validateCommitmentType's allow-list matches the new CHECK exactly. The PK is (id, timestamp), so a relabel can't collide. The CHECK on the parent covers the default partition and the named partitions, and the test inserts into both.
• Ordering: 000141 sits after perf(api): page recommendations from an ID-ordered keyset scan instead of the full list #1240 (000140) and before fix(config/db): seed-group rollbacks, partition-safe 000027 dedupe, fail-closed plan providers, revocation_in_flight clear #1268 (000142). fix(analytics): keep unknown usage and commitment unknown in the savings rollups #1287's 000143 fixtures insert commitment_type = 'RI', which the new CHECK still admits, so the chain composes. previousMigrationVersion is computed.
• Fail-before (both restored afterwards): (a) I swapped commitmentTypeFor's body back to the old "SavingsPlans" literal match, and TestCollectorCollect (2 subtests), TestCommitmentTypeLogic and the real-Postgres TestCollector_GCPCommittedUse_DB failed. (b) I replaced the 000141 up file with SELECT 1;, and TestMigration_SavingsSnapshotsCommitmentTypeVocabulary failed.
• Ran: go build ./...; go vet on analytics and database, with and without -tags integration; go test -race -short and -race -tags integration on internal/analytics (both passed); go test -race -tags integration -run 'CommitmentTypeVocabulary|DownAllRoundTrip|COR02|SavingsSnapshotsPK|SavingsPartitionUTC' ./internal/database/postgres/migrations/, which passed.

Body-stale:

• "Stacked on fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 ... until fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 merges the diff also shows that commit. Review only the last commit, 73bdb19d": fix(purchase,server): skip the $0 purchase confirmation and report a failed lazy DB init on /health #1269 merged on 2026-10-25, so the three-dot diff no longer includes its commit. The head also carries later commits (337d25e4, a test-import fix, and the renumber), so "only the last commit 73bdb19d" is out of date.

_{Reviewer: rE1. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[IAmJSD]

Local verification at 6b229affd6c77b7621b7e42919d7db22ae360fa7 merged onto main (2baf23d5), together with #1240, #1302, #1309, #1454, #1456, #1463 in that order (combined tree d882e3bf, Linux, Go 1.26.10): go build ./..., go vet with and without -tags integration, the full go test -race -short -count=1 ./..., and go test -race -tags integration -count=1 on every changed package, against Docker Postgres. All pass. CI Success and pre-commit are green on this head, with 1 approving independent review(s) on it. Nothing was run against any cloud.

[IAmJSD]

Merged by IAmJSD's agent at IAmJSD's request (IAmJSD is acting owner while the maintainers are away), under the bar IAmJSD set: 1 approving independent review(s) on 6b229aff, green CI, and the combined-tree verification above. Squash-merged at exactly 6b229affd6c77b7621b7e42919d7db22ae360fa7.