[X-Guardian]

Related issue

Fixes #283

Description

Interrupting cdktn diff or cdktn deploy (Ctrl-C) left terraform's state lock held, so the next run failed with Error acquiring the state lock.

The cause was that the CLI's abort handler tore terraform down instead of letting it exit on its own. Terraform shares the CLI's process group, so Ctrl-C already reaches it directly and starts its graceful shutdown (which releases the lock) — but the CLI killed it before that shutdown could finish. The fix is to stop tearing terraform down on abort and instead wait for it to exit:

• diff/plan (@cdktn/commons/src/util.ts): exec() no longer forwards the abort to child_process.spawn's signal option, which killed the child with SIGTERM and rejected the promise immediately (synthetic AbortError) before terraform had exited — so terraform never ran its graceful shutdown and the lock leaked. It now settles on the child's own close, so the run resolves only once terraform has exited and released the lock.

• deploy/destroy (@cdktn/cli-core/src/lib/models/deploy-machine.ts): the xstate machine previously went straight to the final stopped state on STOP, killing the pty and resolving the run before terraform had finished shutting down. It now passes through an intermediate stopping state that marks the run cancelled and waits for terraform's natural EXITED before reaching stopped. The pty stays alive throughout, so terraform exits on its own and the run only resolves afterwards.

Why no extra signal is needed: every abort trigger in the codebase (runCdktfProject, watch) originates from process.on(SIGINT/SIGTERM/SIGQUIT), so terraform — sharing the process group — always receives the signal directly. There is no abort path that requires the CLI to deliver the signal itself.

Verification: confirmed after the fix that a single Ctrl-C produces only Interrupt received... Gracefully shutting down... and terraform exits cleanly on its own. The full lock-release path (interrupt a locking operation, then re-run) still needs a final check against a backend that locks state.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[sakul-learning]

Thanks for taking this on. I ran the PR head through our local termless cdktn-e2e path, including the unmerged e2e test from open-constructs/cdktn-e2e#3, and I’m seeing the diff/http-lock case still reproduce.

Exact setup/checks I ran:

cd /data/repos/cdktn-e2e

# build/publish/install the cdk-terrain PR head into a local sandbox CLI
CDKTN_MONOREPO=/data/repos/hermes-pr-reviewer/worktrees/cdk-terrain/open-constructs__cdk-terrain/pr-284 pnpm provision cdktn-prhead

# static check for the e2e repo
pnpm typecheck

# run the relevant termless interrupt/lock tests against the provisioned PR-head CLI
CLI_ID=cdktn-prhead pnpm exec vitest run tests/diff-lock-release.test.ts tests/ctrl-c-teardown.test.ts

Observed results:

• pnpm provision cdktn-prhead: passed; installed a sandbox CLI from this PR head (0.23.3+prhead).
• pnpm typecheck: passed.
• CLI_ID=cdktn-prhead pnpm exec vitest run tests/diff-lock-release.test.ts tests/ctrl-c-teardown.test.ts: failed, with 2 failing tests and 3 passing tests.

The important failure is the unmerged PR #3 e2e test:

FAIL tests/diff-lock-release.test.ts
Ctrl-C during diff waits for terraform plan to unlock the HTTP backend

That test uses a deterministic in-process Terraform HTTP backend, so it directly records the backend LOCK / UNLOCK requests. Against this PR head I saw the backend receive lock but never unlock, so it reproduces the exact cdktn diff / HTTP-state-lock regression this PR is intended to fix.

I also saw this existing interrupt e2e fail against the same provisioned PR-head CLI:

FAIL tests/ctrl-c-teardown.test.ts
Ctrl-C at the deploy approval prompt exits cleanly and restores the cursor

That one hung after Ctrl-C at the Approve/Dismiss/Stop prompt (waitExit(..., 30_000) returned null).

Could you share how you validated the fix locally, and whether you tried the cdktn-e2e PR #3 test? It’s also possible our e2e harness is modeling the scenario incorrectly, so if you think the deterministic HTTP backend test is wrong I’d like to understand that before treating this as a PR blocker.

[X-Guardian]

I have tested this locally. This is not interrupting Terraform at the approve prompt, but during the plan or apply process.

[jsteinich]

@X-Guardian I think this looks good, but curious what the behavior of a 2nd Ctrl-C press is. My expectation is that it would abort gracefully shutdown.

[X-Guardian]

I tested this and both Ctrl-C's get passed through to Terraform which then responds with:

Two interrupts received. Exiting immediately. Note that data loss may have occurred.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days. This helps our maintainers find and focus on the active issues. If you've found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.