unoverse 0.1.122 → 0.1.124

package/operator/infra/aws/main.tf

@@ -318,8 +318,28 @@ resource "aws_db_instance" "postgres" {
 
   backup_retention_period   = 7
   backup_window             = "03:00-04:00"
-  skip_final_snapshot       = false
-  final_snapshot_identifier = "${var.name}-pg-final"
+  # NO FINAL SNAPSHOT, which is what `unoverse destroy` already promises: "this deletes data
+  # that no backup here can restore" (destroy.sh). The code said otherwise, and the two
+  # disagreed silently.
+  #
+  # A FIXED snapshot name cannot survive a SECOND teardown. `<name>-pg-final` derives only
+  # from the universe name, so teardown one creates it, it persists for ever, and teardown
+  # two is rejected by AWS before the delete even starts:
+  #
+  #   Cannot create the snapshot because a snapshot with the identifier
+  #   unoversedevtest-pg-final already exists
+  #
+  # The instance then sits at `available`, never `deleting`, and everything behind it
+  # strands: the data SG holds its network interface, the app SG is referenced by data's
+  # rules, the alb SG by app's. One rejected call, five resources left billing, and a
+  # teardown that reports it did not finish without saying why. Found 2026-08-05, blocked by
+  # a snapshot a teardown three days earlier had left behind.
+  #
+  # Making the name unique would need a new resource (a random suffix), and `terraform
+  # destroy` cannot create one on its way past. A one-command teardown means no snapshot.
+  # Automated backups (7 days, above) live and die with the instance: take a MANUAL snapshot
+  # before destroying if you want to keep anything.
+  skip_final_snapshot = true
   # POC: no deletion_protection so teardown stays one command. Turn it on at graduation.
 }
 

package/operator/lib/destroy.sh

@@ -48,6 +48,20 @@ cmd_destroy() {
 
   local tmp planfile rc
   tmp=$(mktemp -d); planfile="$tmp/plan"
+
+  # APPLY THE CONFIGURATION FIRST, because destroy does not.
+  #
+  # `terraform destroy` deletes a resource as the last apply left it, so an attribute that
+  # matters only AT DELETE — RDS's `skip_final_snapshot` — comes from STATE, not from
+  # main.tf. Fixing main.tf therefore fixes the next universe and does nothing for one
+  # already applied. Applying the config to the database writes those settings into state
+  # and calls no API; the resource is deleted seconds later, so nothing else here matters.
+  #
+  # It is the standard terraform answer (apply, then destroy) rather than a special case,
+  # and it is best-effort: if it fails, the destroy below reports the real problem.
+  [ "$cloud" = "aws" ] && terraform -chdir="$dir" apply -input=false -auto-approve \
+    -target=aws_db_instance.postgres >"$tmp/sync.log" 2>&1
+
   info "Working out what exists..."
   terraform -chdir="$dir" plan -destroy -input=false -detailed-exitcode -out="$planfile" >"$tmp/log" 2>&1
   rc=$?

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "unoverse",
-  "version": "0.1.122",
+  "version": "0.1.124",
   "description": "The Unoverse front door — create a Studio project, a universe, or a client app, and launch Studio.",
   "license": "SEE LICENSE IN README.md",
   "type": "module",