admin: block org deletion while the warehouse exists; confirm modals#892
Merged
Conversation
Deleting an org in the admin UI removed only the config rows, silently
orphaning the org's Duckling CR and its infrastructure (S3 bucket,
metadata database, IAM role) — the drift banner caught exactly this in
dev. Enforce the correct order: deprovision the warehouse (provisioner
tears down the CR and removes the row), then delete the org.
- DeleteOrg checks for a managed-warehouse row inside the delete
transaction and refuses with a sentinel; the handler maps it to 409
("deprovision it and wait for teardown to complete"). Handler tests
for both the rejection and the post-teardown success path.
- Admin UI gains a Deprovision warehouse action (danger zone in the
warehouse panel) with a type-the-org-id confirmation modal spelling
out what gets destroyed, wired to POST /orgs/:id/deprovision.
- Org deletion is type-to-confirm too; while a warehouse exists the
header Delete button is disabled with an immediate tooltip and the
dialog hard-disables confirm (server 409 as backstop).
Test Impact PlanDeterministic summary of how this PR changes tests, CI runners, and coverage-risk signals. Summary
Signals
Coverage risk: neutral or increased No coverage-reduction warnings detected. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deleting an org in the admin UI removed only the config rows, silently orphaning the org's Duckling CR and its infrastructure (S3 bucket, metadata database, IAM role). The drift banner caught exactly this in dev after an org delete. This enforces the correct order: deprovision the warehouse (the provisioner tears down the CR + infra and removes the row) → then delete the org.
Backend
DeleteOrgchecks for a managed-warehouse row inside the delete transaction and refuses with a sentinel error; the handler maps it to 409 ("warehouse still exists — deprovision it and wait for teardown to complete before deleting the org"). 404/500 behavior unchanged;apiStoreinterface untouched.Admin UI
POST /orgs/:id/deprovision. Confirmation modal spells out what gets destroyed (Duckling CR, S3 data bucket, metadata DB, IAM role; asynchronous) and requires typing the org id to arm the button.Verification
go build -tags kubernetes ./...,go vet,gofmt— clean; new handler tests pass (remaining local skips are the pre-existing Postgres-container tests, run in CI).npm run build— clean. Reviewed live against mw-dev via the dev proxy.🤖 Generated with Claude Code