cli: Crash on failed deploy

[jsteinich]

Expected Behavior

No crash on failed deploy with just the error displayed

Actual Behavior

Crash on deploy failure after displaying the error.

187  docker_image.nginxImage: Creating...
187  ╷
│ Error: failed to create Docker client: Error pinging Docker server, please make sure that npipe:////./pipe/docker_engine is reachable and has a  '_ping' endpoint. Error: error during connect: in the default daemon configuration on Windows, the docker client must be run with elevated privileges to connect: Head "http://%2F%2F.%2Fpipe%2Fdocker_engine/_ping": open //./pipe/docker_engine: The system cannot find the file specified.
│
│   with docker_image.nginxImage (nginxImage),
│   on cdk.tf.json line 46, in resource.docker_image.nginxImage (nginxImage):
│   46:       }
│
╵
undefined
undefined
Collecting Debug Information...
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Invoking Terraform CLI failed with exit code 1
(node:33900) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 11)
(Use `node --trace-warnings ...` to show where the warning was created)
Debug Information:
language: typescript
cdktn-cli: 0.24.0-pre.91
node: v22.22.2
cdktn: 0.23.1
cdktf: null
constructs: 10.6.0
jsii: null
terraform: 1.14.3
arch: x64
os: win32 10.0.26200

Steps to Reproduce

1. Setup a project from cdktn-cli: Deployment options not working as expected #187
2. Run cdktn deploy while docker is not running
3. Observe the issue

Versions

language: typescript
cdktn-cli: 0.24.0-pre.91
node: v22.22.2
cdktn: 0.24.0-pre.91
cdktf: null
constructs: 10.6.0
jsii: null
terraform: 1.14.3
arch: x64
os: win32 10.0.26200
providers
aws@~> 6.45 (LOCAL)
terraform provider version: 6.56.0

Migration Context

Not sure / don't remember

Upstream cdktf Issue

No response

Providers

No response

Gist

No response

Possible Solutions

No response

Workarounds

No response

Anything Else?

No response

References

• cdktn-cli: Deployment options not working as expected #187
• cli: Extra noise displayed on errored plan #360

Help Wanted

• I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[so0k]

macOS triage of #359, #360, #361 — and our position on cutting 0.24

Thanks for filing these three while testing on Windows. The open question was whether they are Windows-specific, so we spent a pass trying to reproduce all three on macOS (darwin arm64, Node 24.18.0 and Node 22.22.x via mise, CLI built from origin/main @ e1cf8ce03), using only local failure modes — hashicorp/null / terraform_data + local-exec, and an intentionally invalid assume_role_policy that Terraform rejects during schema validation. No cloud credentials were used and no real infrastructure was created.

Headline: all three are cross-platform in code, not Windows bugs. We grepped tty-stream.ts, project-runner.ts, util.ts, cdktn.ts and terraform-cli.ts for process.platform / win32 — zero hits. Windows isn't special-cased anywhere; it just lands differently on a terminal rendering model (#359) and on a timing race (#360/#361). For #361, macOS is actually worse than what you saw.

---

#359 — status bar text flashes while the spinner spins

Reproduced on macOS: mechanism yes, visible symptom unverified. We captured raw ANSI byte streams from a real macOS pty (script -q) and confirmed the CLI performs a full erase-and-rewrite of the entire bar (spinner glyph and label together) roughly every 80 ms, plus two more full repaints per log line during deploy. What we did not do is sit and watch a rendered Terminal.app/iTerm2 window, so we cannot claim a human-perceptible flash on macOS — only that the repaint loop that would cause it fires identically here. Please read our "reproduced" as a code-level claim, not a visual one.

Likely cause — three uncoordinated repaint triggers, none debounced:

• packages/cdktn-cli/src/bin/cmds/helper/tty-stream.ts:155 — paintBar() always rewrites glyph + label; never updates the glyph in place.
• packages/cdktn-cli/src/bin/cmds/helper/tty-stream.ts:181 — startSpinner()'s unthrottled 80 ms setInterval calls eraseBar() + paintBar() every tick even when the label is unchanged.
• packages/cdktn-cli/src/bin/cmds/helper/tty-stream.ts:86 — appendLog() does its own erase + repaint per line.
• packages/cdktn-cli/src/bin/cmds/helper/project-runner.ts:113-116 — fires opts.onLog?.(event) and then unconditionally fireStatus(runningStatus(project)), so every log line causes two full bar repaints back-to-back on top of the spinner's own cadence.

Severity: cosmetic, TTY-only. StreamRenderer skips the bar entirely when this.tty is false, so CI logs are unaffected.

Worth flagging honestly: this is the one genuine 0.24 regression of the three. tty-stream.ts was introduced by a6aff7e6c (2026-07-03, #264, the Ink + React removal) and has never shipped in a stable tag. So it is a real cost of that change. We also did not A/B against 0.23's Ink renderer, so we can't say whether flicker got worse, better, or merely different.

---

#360 — Terraform error printed twice, plus a trailing rejection dump

This is two separate symptoms and should probably be split.

(a) Duplicated error block — reproduced on macOS, 7/7 runs (Node 24 and Node 22.22.2 to match yours, both piped and under a real pty). Not a rendering artifact: it survives > file 2>&1 byte-for-byte.

Likely cause: packages/@cdktn/commons/src/util.ts:166-171 — exec() unconditionally tees every stderr chunk to processLoggerError() even when a stderr callback was supplied. The callback path (terraform-cli.ts:274 → execution-logs.ts:32 → cmds/ui/diff.ts:69) then renders the same text again with construct-path annotations. Note the asymmetry: the stdout branch ~10 lines earlier correctly uses processLoggerDebug. Pre-existing since 4f16a69c6 (2023-09-20).

Severity: noise. The error text is fully present, and the External Error: Stack failed to plan summary (cdktf-project.ts:417) is correct and printed once.

(b) The trailing unhandled-rejection block: never reproduced on macOS, 0/7 runs, including on your exact Node 22.22.2. Reading your log closely, the rejected reason there is Error: terraform plan ... exited with code 1 (minted in exec()'s close handler, util.ts:~188) — a different rejected promise from #361's, but hitting the same un-awaited handler. We believe (b) is the same defect as #361 and should be tracked there. That is an inference from comparing your log to the code, not an observed macOS repro.

Two caveats on this repro: it needed skipValidation: true to bypass an unrelated CDK-side validation, and we hand-corrected the generated cdk.tf.json because an L1 TerraformProvider usage emitted a malformed provider block. The hand-edit is cosmetic w.r.t. the duplication bug, but it means this isn't a clean end-to-end path — and that malformed provider block may be a distinct bug nobody has looked at.

---

#361 — undefined / undefined then an unhandled rejection on failed deploy

Reproduced on macOS: yes, and it is worse here than on Windows. Using a terraform_data resource with a local-exec provisioner that runs exit 1 (no Docker, no network, no cloud provider — a completely different trigger from your npipe/Docker failure), the process hard-aborts with ERR_UNHANDLED_REJECTION on both Node 24.18.0 and Node 22.22.3. Your Windows run got the survivable PromiseRejectionHandledWarning and went on to print Debug Information:; ours never gets there. Same defect, opposite side of the race. This is a real crash and it is cross-platform — stating that plainly even though it's inconvenient for the release.

Likely cause — two stacked defects:

1. Cosmetic (the two undefined lines): packages/@cdktn/cli-core/src/lib/models/terraform-cli.ts:429 throws a raw string, not an Error. packages/cdktn-cli/src/bin/cdktn.ts:172-174 then does console.error(error.message) / console.error(error.stack), which are undefined on a string primitive. Deterministic, platform-independent.
2. The crash: packages/cdktn-cli/src/bin/cdktn.ts:159 registers an async yargs .fail() handler — its own comment at 160-162 says "yargs is not waiting for this async function." yargs 17.7.3 invokes it fire-and-forget (node_modules/yargs/build/lib/usage.js:39, return value never captured), and the handler then does real async work (await collectDebugInformation() at cdktn.ts:176, await Sentry.close(4000)) before process.exit(1). There is no process.on("unhandledRejection", ...) anywhere in packages/. So the rejection races Node's unhandled-rejection sweep — lose the race, hard abort; win it barely, warning + clean finish.

One correction to a fix that looks obvious but isn't sufficient: making terraform-cli.ts:429 throw Errors.External(...) removes the undefined lines and shortens the async window, but does not close the race. Your own #360 log proves that — it reached the same state via the typed-Errors.External short branch. Only restructuring cdktn.ts (e.g. parseAsync() with a real await, or an explicit unhandledRejection handler) actually fixes it. Whoever picks this up should know that up front.

Severity: crash, but it does not eat the error message. In our runs the complete Terraform error box printed in full before the abort, and the exit code was still 1 — so CI and wrapper scripts still detect failure correctly, and there is no silent-success risk. What is lost is the tail: the Debug Information: block never prints, Sentry.close() never runs, and output ends in undefined / undefined plus a Node internals stack trace. It fires on essentially every non-zero Terraform exit.

---

Position on cutting 0.24

We think 0.24 is safe to cut, and per our agreement we are not planning to fix these ourselves before the cut. Reasoning:

• cli: Extra noise displayed on errored plan #360 and cli: Crash on failed deploy #361 are not 0.24 regressions. git blame: the string throw dates to 92274f937 (2022-12-08), the async .fail() to 036114321 (2023-08-16), the stderr tee to 4f16a69c6 (2023-09-20). All of it shipped in 0.23 and every prior release, unchanged. Holding 0.24 protects nobody from them; cutting makes nothing worse.
• cli: Action text flashes while the spinner is active #359 is new in this cycle, but it's cosmetic, TTY-only, and invisible in CI.
• cli: Crash on failed deploy #361 was the real judgement call. Against the stated bar — "a crash on failed deploy might be a blocker because it destroys the error message users need" — it fails that bar: the error message survives intact and the exit code is still correct. It's ugly and it fires often, but it is not new and it is not information-destroying.

Two soft costs we want on the record rather than buried: the truncated Debug Information: block is exactly what our bug-report template asks reporters to paste, so shipping this degrades every incoming 0.24 bug report; and aborting before Sentry.close() plausibly means failed-deploy telemetry is being dropped (inferred from output ordering — not instrumented or verified).

If you want one cheap pre-cut win, our pick is packages/@cdktn/commons/src/util.ts:170 — processLoggerError → processLoggerDebug in the callback-supplied branch only. One line, matches what the stdout branch already does, kills #360(a). We'd explicitly recommend against rushing the cdktn.ts .fail() restructure into a release cut: it's the top-level error path for every command, it's a race, and it needs more than the one-line typed-throw fix. That belongs in 0.24.x with a test.

---

What we did not verify

Being explicit so nobody over-reads the above:

• No Windows host was available. Nothing about your actual platform was tested. Our explanations for why Windows differs (conhost's synchronous per-write redraw for cli: Action text flashes while the spinner is active #359; subprocess/pty timing landing on the survivable side of the race for cli: Extra noise displayed on errored plan #360/cli: Crash on failed deploy #361) are reasoning from documentation, not measurement.
• cli: Action text flashes while the spinner is active #359's visible flash was never observed on macOS — bytes only, no rendered frame, no timing/vsync.
• cli: Action text flashes while the spinner is active #359 was not A/B'd against 0.23's Ink renderer.
• cli: Extra noise displayed on errored plan #360 was not re-run in the final pass — the 7/7 figure comes from the earlier repro session; the final pass only re-read the code and your issue body. Its repro also required a hand-edited cdk.tf.json (see above).
• cli: Extra noise displayed on errored plan #360's rejection tail was never reproduced anywhere on macOS (0/7, including your exact Node version). Our claim that it's the same defect as cli: Crash on failed deploy #361 is code + log reading.
• cli: Crash on failed deploy #361 was re-verified on Node 24 in the final pass; the Node 22.22.3 result is from the earlier session. Neither used your exact 22.22.2. The repro also used --skip-synth against a hand-written cdktf.out/, so the synth path wasn't exercised for it.
• No fix was implemented or tested for any of the three. Every "this would fix it" above — including our claim that the cdktn.ts restructure closes the race — is untested reasoning.
• The "not a 0.24 regression" claim rests on git blame, not on running 0.23. The error-path code is provably unchanged since 2022/2023, but chore(cli): replace Ink + React with smaller-tree CLI libraries #264 replaced the renderer and therefore changed output/teardown flush behaviour, which could plausibly shift the timing of a race this tight. We did not build a pre-chore(cli): replace Ink + React with smaller-tree CLI libraries #264 CLI to check whether 0.23 crashed the same way. This is load-bearing for our safe-to-cut recommendation — if you want it airtight, that build is the missing experiment, and we're happy to run it before you cut if you'd rather not take it on inference.
• No test suite was run, so we don't know whether these behaviours are currently locked in by passing tests or whether a fix would be caught by regressions.

Happy to be overruled on any of this, particularly #361 — if you'd rather treat a hard abort on every failed deploy as a blocker regardless of it being pre-existing, that's a defensible call and we'll hold.

[so0k]

Corrected: I posted this without having read the earlier triage in this thread. The macOS reproduction and the .fail() mechanism were already established there, in more depth — my original framing of "this is not Windows-specific" was redundant. Rewritten to keep only what is actually additive.

Two things that may still be useful.

1. A simpler trigger that exercises the real init path

The earlier repro was explicitly caveated as using --skip-synth against a hand-written cdktf.out/, so the synth/init path wasn't covered. This one needs no fixture, no provider, and no failing resource — just cdktn deploy, then CTRL+C during terraform init:

│ Error: Provider installation was canceled by an interrupt signal.
╵
terraform init failed with exit code 1
Error: terraform init failed with exit code 1
    at async FX.init (handlers.js:332:9873)
    at async YX.initalizeTerraform (handlers.js:336:211)
    at async aJ.initializeStacksToRunInSerial (handlers.js:371:39723)
    at async aJ.deploy (handlers.js:371:37051)
    at async jVe (handlers.js:430:139)
Collecting Debug Information...
This error originated either by throwing inside of an async function without a catch block, or by
rejecting a promise that was not handled with .catch(). The promise rejected with the reason:
Error: terraform init failed with exit code 1
    ... (the identical stack, printed a second time)
(node:96177) PromiseRejectionHandledWarning: Promise rejection was handled asynchronously (rejection id: 11)

darwin 25.5.0 arm64, Node v24.18.0, cdktn-cli@0.24.0-pre.91, terraform 1.15.8.

One detail that supports the race reading: this lands on the survivable side — PromiseRejectionHandledWarning plus the double print, reaching Debug Information: — rather than the hard ERR_UNHANDLED_REJECTION abort seen with the local-exec exit 1 trigger on the same OS and Node version. So the outcome varies by trigger within macOS alone, not just between platforms.

Also worth noting the CTRL+C asymmetry: interrupting during synth exits cleanly with no stack trace; interrupting during init/plan produces the above.

2. The same branch is reached from a successful deploy

A Sentry report from a 0.24.0 user hits the same else if (error) branch, with breadcrumbs matching it in order:

breadcrumb	source
Cannot convert undefined or null to object	console.error(error.message)
TypeError: ... at Object.entries ...	console.error(error.stack)
Collecting Debug Information...	the literal string

Completely different root cause — a crash in the outputs renderer after both stacks applied successfully, not a failed deploy — and it has its own targeted fix in progress, which we'll raise separately. Relevant here only as evidence of how much this handler carries: it is the final common path for unrelated failures and mishandles them identically. That strengthens the existing recommendation to fix it properly in 0.24.x with a test, rather than as a quick pre-cut patch.