chore(db): drop deprecated (aws, sagemaker) service_configs row (closes #133)#227
Conversation
#133) Migration 000040 (PR #123) split the legacy `(aws, savings-plans)` umbrella into four per-plan-type rows and copied PR #71's `(aws, sagemaker)` term/payment forward into the new `(aws, savings-plans-sagemaker)` row, but intentionally KEPT the deprecated `(aws, sagemaker)` row for one stable release behind a SQL deprecation comment so users mid-rollout would not lose their save. Now that the per-plan-type cards are canonical, this follow-up migration removes the deprecated row. Up: idempotent `DELETE FROM service_configs WHERE provider = 'aws' AND service = 'sagemaker'` — safe no-op on installations that never had PR #71's row or that already ran this migration. Down: emergency rollback recreates the row by INSERT...SELECT from `(aws, savings-plans-sagemaker)`, lossy by design (only the post-040 term/payment survive). `ON CONFLICT (provider, service) DO NOTHING` keeps an existing row untouched; an empty SELECT (no `savings-plans-sagemaker` row to source from) yields a no-op INSERT. Production-code grep confirms no callers reference the bare `'sagemaker'` service slug — all references are to the `savings-plans-sagemaker` / `savingsplans-sagemaker` slugs introduced by 000040 and consumed by `cmd/main.go`, `internal/purchase/execution.go`, and `pkg/common/types.go`. Updates `split_savingsplans_test.go` scenario 2 to reflect the new post-migration state: the `(aws, sagemaker)` row is now absent after running all migrations. The "sagemaker slot inherits from PR #71's row" assertion still holds because 000040 copies the values forward before 000045 deletes the source row.
|
@coderabbitai review |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughMigration 000045 removes the deprecated ChangesDatabase Cleanup Migration
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Review rate limit: 4/5 reviews remaining, refill in 12 minutes. Comment |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Summary
Closes #133.
Migration 000040 (PR #123) split
(aws, savings-plans)into fourper-plan-type rows and copied PR #71's
(aws, sagemaker)term/paymentforward into
(aws, savings-plans-sagemaker), but intentionally KEPTthe deprecated
(aws, sagemaker)row for one stable release as abackward-compat safety net (see the
Deprecation follow-upcomment atthe bottom of
000040_split_savingsplans.up.sql). This PR ships thefollow-up migration that removes that deprecated row now that the
per-plan-type cards are canonical.
Gap
(aws, sagemaker)still exists inservice_configsafter PR #123landed. Per-plan-type cards now drive SageMaker SP defaults via the
(aws, savings-plans-sagemaker)row, so the legacy row is dead state.Fix
New migration
000045_drop_aws_sagemaker_service_config.{up,down}.sql:DELETE FROM service_configs WHERE provider = 'aws' AND service = 'sagemaker'. WHERE clause makes it a safe no-op oninstallations that never had PR ux(settings): add SageMaker and Lambda purchasing-defaults cards #71's row, or that already ran this
migration.
INSERT...SELECTfrom(aws, savings-plans-sagemaker), lossy bydesign (only post-040 term/payment survive — any divergent edits to
(aws, sagemaker)between 000040 and 000045 are not recoverable).Idempotent in two directions:
back first).
ON CONFLICT (provider, service) DO NOTHINGkeeps it untouched.
Also updates
split_savingsplans_test.goscenario 2 (integration-taggedtest) to reflect the new post-migration state:
(aws, sagemaker)is nowabsent after running all migrations. The "sagemaker slot inherits 1,
partial-upfront" assertion still holds because 000040 runs before
000045 and copies the values forward into the persisted split row
before the source row is deleted.
Blast-radius check (production code paths)
Grepped
internal/,pkg/,cmd/(excluding_test.go) forreferences to the bare
'sagemaker'service slug — zero hits. Allproduction references are to:
pkg/common/types.go:ServiceSavingsPlansSageMaker = "savings-plans-sagemaker"cmd/main.go,internal/purchase/execution.go: maps from"savings-plans-sagemaker"and"savingsplans-sagemaker"to thetyped constant.
internal/config/defaults.go,internal/config/README.md:aws.savings_plans.sagemaker_enabledconfig key (independent of theservice_configs row).
The only callers of the bare
(aws, sagemaker)service_configs rowwere the SQL paths inside migration 000040 (now historic), which read
it during the split and are not re-run.
Test plan
go build ./...— green.go vet -tags=integration ./internal/database/postgres/migrations/...— green; integration-tagged test compiles with the updated scenario 2 expectations.'sagemaker'— empty.TestMigration_SplitSavingsPlansplus the JSONB rewrite test against a real Postgres container; scenario 2 now requires 4 rows (down from 5) andhasSagemaker == false.(aws, sagemaker)from the current(aws, savings-plans-sagemaker)row.Summary by CodeRabbit