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

[jwfing]

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.

^{Written for commit 6d5f5c3. Summary will update on new commits.}

[jwfing]

Docs mirror: InsForge/instacloud-skills#174

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="test/limits.test.ts">

<violation number="1" location="test/limits.test.ts:171">
P3: This fixture cannot verify that HTTP 202 alone triggers the pending message because `pending: true` independently satisfies the condition. Remove that flag here; the next test already covers the 200/pending case.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

View guided diff | Turn on auto-fix | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: This fixture cannot verify that HTTP 202 alone triggers the pending message because pending: true independently satisfies the condition. Remove that flag here; the next test already covers the 200/pending case.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At test/limits.test.ts, line 171:

<comment>This fixture cannot verify that HTTP 202 alone triggers the pending message because `pending: true` independently satisfies the condition. Remove that flag here; the next test already covers the 200/pending case.</comment>

<file context>
@@ -164,6 +164,26 @@ describe('postgres always-on set confirmation', () => {
+// reported the OLD ceiling as the new one (instacloud-cli#369).
+describe('postgres limits set confirmation', () => {
+  it('on 202 prints the requested values as not applied yet, never the pre-change row', () => {
+    const line = limitsSetLine('db', undefined, { memory: '2Gi' }, { status: 202, body: { cpuMilli: 4000, memoryMib: 4096, pending: true } })
+    expect(line).toBe('postgres db: ceiling 2Gi requested, not applied yet — confirm with `insta postgres limits db`')
+    expect(line).not.toContain('4 GiB')
</file context>

Suggested change

	const line = limitsSetLine('db', undefined, { memory: '2Gi' }, { status: 202, body: { cpuMilli: 4000, memoryMib: 4096, pending: true } })
	const line = limitsSetLine('db', undefined, { memory: '2Gi' }, { status: 202, body: { cpuMilli: 4000, memoryMib: 4096 } })

[jwfing]

Verdict: approved. This is a COMMENT review; human approval is still required.

Reviewed all three changed files against main / merge-base 501bdee, head 6d5f5c3 (not stacked), including the dbLimits caller, parsing, rawRequest, approval handling, JSON output, and existing tests. Issue #369 points 1–2 are implemented: 202 or pending responses report requested values without treating the old row as applied; applied responses retain their confirmation; always-on wording now reflects the database default. Point 3 is intentionally deferred. The companion skills PR #174 supplies the pending-output documentation.

Findings: Critical 0; Suggestion 1 (already reported); Information 0.

Suggestion — test/limits.test.ts:171: I agree with the existing coverage comment. With both status 202 and pending:true, deleting the status-only condition would still pass this fixture. Remove pending from this fixture or add a 202-only case to protect that contract. This is non-blocking; I independently exercised 202 without pending and verified the correct output. No duplicate inline finding added, and no additional actionable findings identified in this scope.

Validation: npm run typecheck passed; npm test passed (104 files, 2170 tests); a direct node --import tsx assertion for 202 without pending, with service and branch, passed; git diff --check passed. Existing installed dependencies were reused in the isolated review worktree. No production calls or live resize were performed; Windows execution was not verified locally. This repository has no docs/ or docs/superpowers/ directory, so scope was checked against #369 and the explicit issue instructions. Companion #174 was inspected for documentation consistency, not separately given a full review.

[Fermionic-Lyu]

LGTM, Approved.