fix(postgres): limits says a queued resize is not applied yet; databases default to always-on (IOZI-30)

Merged
JW
3d ago
+46-9

Fixes #369 (IOZI-30): points 1 and 2. Point 3 is a product decision and is left open below.

insta postgres limits db --memory 2Gi
# before: postgres db: ceiling set to 4 vCPU / 4 GiB        <- the row from before the patch
# after:  postgres db: ceiling 2Gi requested, not applied yet — confirm with `insta postgres limits db`

Changes

  • postgres limits (set): insta-db queues a cpu/memory PATCH and answers 202 with the instance row from before the patch. The platform adds pending: true.
    • New pure seam limitsSetLine in src/commands/postgres.ts. On status === 202 or pending: true it prints the requested values and points at the read-back, including [service] and --branch when given. This is the same approach alwaysOnSetLine takes.
    • An applied response (200, not pending) still confirms from cpuMilli / memoryMib the same way as before.
    • I print and hand off instead of polling the way waitForScaleToZero does. A resize restarts the pod and can take longer than a CLI should block for. The read-back is one command away.
    • --json is unchanged and still passes the raw body through, pending included.
  • Stale default wording (platform #666, databases are born always-on):
    • the comment above dbAlwaysOn (was :20);
    • the alwaysOnSetLine confirmation (was :73): disabled no longer says "(default; …)", and ENABLED now notes that it is the database default;
    • the postgres always-on help in src/index.ts, which said "off = default scale-to-zero".
  • Docs mirror: InsForge/instacloud-skills PR (linked in a comment below) adds the pending note to the postgres limits row of insta/cli-reference.md. The stale "off (default)" on the postgres always-on row is left to the in-flight IOZI-31 docs branch, so the two don't conflict.

Open question (point 3): allow service add postgres --no-always-on?

Not implemented. services.ts:167 still refuses --always-on / --no-always-on for every non-compute type.

For

  • The platform already accepts alwaysOn for databases at create (serviceFields.ts), so this would be a small change in the CLI only.
  • Without it, getting a scale-to-zero database takes two steps (service add, then postgres always-on off). For a moment the database runs always-on and is billed for idle RAM.
  • Compute already has the flag pair, so the create surface would work the same way for both.

Against

  • Always-on became the database default on purpose, to stop cold starts on the first connection. A create-time opt-out makes the cold-start path easy to choose by accident.
  • postgres always-on off already exists and can be undone. The flag only saves one command.
  • It would apply to postgres only. redis / mysql / mongodb handle always-on differently, so the "non-compute → refused" rule would get a special case. cli-reference.md would also need to describe the split.

Recommendation: leave it out until someone asks for it. If we add it, add only --no-always-on for postgres (--always-on is already the default), with a test.

Tests

npm run typecheck && npm test: 104 files / 2170 tests pass.

New cases in test/limits.test.ts (postgres limits set confirmation):

  • a 202 prints the requested value and never the pre-change 4 GiB;
  • pending: true without a 202 is also not applied, and the read-back names --branch;
  • an applied 200 confirms from the reported row.

🤖 Generated with Claude Code

Summary by cubic

Fixes postgres limits so a queued (pending) resize no longer echoes the pre-change row as the new ceiling, and updates the CLI wording that still called scale-to-zero the database default.

Bug Fixes

  • When the provider answers 202 or marks pending: true, prints the requested limit as "not applied yet" and points to the read-back, scoped to the service and branch if given; an applied 200 still confirms from the reported row.
  • --json output is unchanged and still passes the raw body, pending included.
  • postgres always-on help, the setting comment, and the enabled confirmation now reflect that databases default to always-on (platform #666); "off" is no longer labeled the default.