generateCommand exits the process instead of throwing, so callers cannot clean up

[borisno2]

Parent

Follow-up from #1157 / #1218, under spec #1125. Lands on the prisma-8 integration branch, not main.

Problem

generateCommand() in packages/cli/src/commands/generate.ts reports every failure by calling process.exit(1) — around 13 call sites. That is fine for opensaas generate, which is the whole process, but it is now wrong for opensaas dev, which calls generateCommand() as one step of a longer-lived loop that owns resources.

process.exit skips finally blocks and never drains pending async work, so a try/finally in the dev loop cannot run its async stop() on this path no matter where the try starts. When generation fails under opensaas dev, the in-process PGlite is never closed cleanly.

#1218 mitigated what is reachable from a synchronous 'exit' listener — it kills the app child and drops the run's state file, which closes the worst hole (an orphaned next dev left running against a dead database). The clean async shutdown still needs the underlying contract to change.

What to build

Make generateCommand() signal failure by throwing rather than by exiting, so callers decide what to do. The opensaas generate command keeps its current observable behaviour — same message, same exit code — by catching at the CLI entry point. opensaas dev then gets its finally back and can await a clean stop().

Expect a contract change for every caller; check packages/cli/src/index.ts and the dev loop, and any test that asserts on the exit.

Acceptance criteria

• generateCommand() throws on failure; no process.exit inside it
• opensaas generate on a failing config still prints the same error and exits 1
• Under opensaas dev, a generation failure runs the loop's async stop() — the Dev database is closed and its state file removed, verified by a test rather than by inspection
• The synchronous 'exit' safety net added in opensaas dev brings up the Dev database, generates, reconciles and spawns the app #1218 is reconciled with the new path: kept as a backstop or removed as redundant, deliberately either way

Notes

Raised by the implementer of #1218 while addressing review, and deliberately left out of that PR: refactoring 13 exit sites and changing a contract for every caller does not belong in a PR already under review.

[borisno2]

Adjacent shutdown defect found in the same verification pass on #1218, worth handling by whoever takes this issue since it is the same code path:

Handlers are process.once, so a second Ctrl-C falls back to default termination and runs neither the finally nor the 'exit' listener — the realistic sequence when the child ignores the first interrupt.

The impatient double Ctrl-C is exactly how a developer reacts when the app child does not die promptly, so the leak this issue is about is reachable by an ordinary keystroke, not only by a generation failure. Once generateCommand throws and the loop's finally genuinely owns cleanup, the signal handlers should be reconsidered together with it: a second interrupt wants to escalate the child's termination, not bypass the parent's cleanup.

[borisno2]

Substantially addressed by #1225 (ebb09c9f), but not fully — leaving this open, with the remainder narrowed.

What landed: all 13 internal process.exit(1) sites in generateCommand are gone. Every failure now throws a GenerationFailedError, funnelled through a single boundary at packages/cli/src/commands/generate.ts:129-130:

if (options.throwOnFailure === true) throw error
process.exit(1)

The dev loop passes throwOnFailure, so it gets its finally back and shuts the Dev database down cleanly on a generation failure — which was the reachable harm this issue was filed for. opensaas generate keeps its existing behaviour through the default branch.

What remains, and why it still matters: the default is still to exit, so the trap is intact for the next caller who does not know to opt out. The acceptance criterion here was "no process.exit inside it" — the cleaner end state is generateCommand always throwing, with packages/cli/src/index.ts catching and exiting, which is where an exit belongs. That inverts the default so a new caller gets the safe behaviour without knowing to ask.

Also still open from this issue's later comment: the process.once signal handlers mean a second Ctrl-C bypasses cleanup entirely — the realistic sequence when the child ignores the first interrupt. That was not touched by #1225.

Remaining acceptance criteria:

• generateCommand always throws; the exit moves to the CLI entry point
• opensaas generate on a failing config still prints the same error and exits 1
• A second Ctrl-C escalates the child's termination rather than bypassing the parent's cleanup
• The synchronous 'exit' safety net in the dev loop is reconciled with the above — kept as a backstop or removed as redundant, deliberately either way