fix(aws-cdk-lib): toolkit is unaware of CDK app errors#37294
Merged
mergify[bot] merged 2 commits intomainfrom Mar 20, 2026
Merged
fix(aws-cdk-lib): toolkit is unaware of CDK app errors#37294mergify[bot] merged 2 commits intomainfrom
mergify[bot] merged 2 commits intomainfrom
Conversation
We want to know about the synth errors that happened in the CDK app in
the Toolkit. In order to do that, we are doing the following things:
We print the error code between special markers. We have chosen the
guillemet to print the error codes: `«InvalidBucketName»`. It nicely
braces the error, look visually appealing, and is uncommon enough that
it is unlikely to appear in the output of a CDK app already
accidentally.
The CLI will scan `stdout` and `stderr` for text between these markers.
That approach is chosen because it will work regardless of whether the
CDK app is executing via jsii or not (`uncaughtException` handlers will
only work for direct Node programs, not jsii programs).
In order for this masterful scheme not to be foiled by a customer
putting the following into their program:
```ts
console.log('«IveTrickedYouIntoCollectingCustomerContent»');
```
Whenever an error with an error code is constructed, we write the code
to special file that is indicated by the `CDK_ERROR_FILE` environment
variable (which will be set by the Toolkit). Only codes that appear in
that file are eligible for scanning from `stderr`/`stdout`, so that
we are not tricked into collecting customer content.
Why don't we just take the error code in that file as gospel? Because
the exception could be caught and the program continued. That an Error
object is produced doesn't mean it terminates the program.
aws-cdk-automation
previously requested changes
Mar 20, 2026
otaviomacedo
approved these changes
Mar 20, 2026
rix0rrr
added
pr-linter/exempt-test
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Contributor
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Contributor
Merge Queue Status
This pull request spent 30 minutes 40 seconds in the queue, including 30 minutes 27 seconds running CI. Required conditions to merge
|
Contributor
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
Contributor
|
Comments on closed issues and PRs are hard for our team to see. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We want to know about the synth errors that happened in the CDK app in the Toolkit. In order to do that, we are doing the following things:
We print the error code between special markers. We have chosen the guillemet to print the error codes:
«InvalidBucketName». It nicely braces the error, look visually appealing, and is uncommon enough that it is unlikely to appear in the output of a CDK app already accidentally.The CLI will scan
stdoutandstderrfor text between these markers. That approach is chosen because it will work regardless of whether the CDK app is executing via jsii or not (uncaughtExceptionhandlers will only work for direct Node programs, not jsii programs).In order for this masterful scheme not to be foiled by a customer putting the following into their program:
Whenever an error with an error code is constructed, we write the code to special file that is indicated by the
CDK_ERROR_FILEenvironment variable (which will be set by the Toolkit). Only codes that appear in that file are eligible for scanning fromstderr/stdout, so that we are not tricked into collecting customer content.Why don't we just take the error code in that file as gospel? Because the exception could be caught and the program continued. That an Error object is produced doesn't mean it terminates the program.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license