cdklocal fails silently

[iiian]

The regular cdk will do a good job of telling you which dependency bonked cloudformation. However, when I run cdklocal, I'm running into an issue where it fails silently, forcing me to go and try to check the diagnostic endpoint, which now also seems to be failing as of 0.14.1 (even if I try and set DEBUG=1, and LS_LOG=trace).

Log output from running cdklocal bootstrap & cdklocal deploy:

 ⏳  Bootstrapping environment aws://000000000000/us-west-1...
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
Using default execution policy of 'arn:aws:iam::aws:policy/AdministratorAccess'. Pass '--cloudformation-execution-policies' to customize.
CDKToolkit: creating CloudFormation changeset...
[███████████▎·········································] (3/14)

12:58:59 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDK
Toolkit
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
[██████████████████▉··································] (5/14)

12:58:59 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDK
Toolkit
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
[██████████████████████████████▎······················] (8/14)

12:58:59 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDK
Toolkit
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
[██████████████████████████████████···················] (9/14)

12:58:59 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDK
Toolkit
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
[█████████████████████████████████████████▋···········] (11/14)

12:58:59 PM | CREATE_IN_PROGRESS   | AWS::CloudFormation::Stack | CDK
Toolkit
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
[█████████████████████████████████████████████████████] (14/14)

12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccounts
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Tru
stedAccountsForLookup
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Clo
udFormationExecutionPolicies
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Fil
eAssetsBucketKmsKeyId
12:58:59 PM | UPDATE_IN_PROGRESS   | AWS::CloudFormation::Stack | Pub




































 ✅  Environment aws://000000000000/us-west-1 bootstrapped.


✨  Synthesis time: 57.64s

test-docustream-stack: deploying...
[0%] start: Publishing 4daba9f5664e819d75849c3857fde6298abaf0c71a9e35f73465760434e91537:current_account-current_region
[100%] success: Published 4daba9f5664e819d75849c3857fde6298abaf0c71a9e35f73465760434e91537:current_account-current_region
test-docustream-stack: creating CloudFormation changeset...










 ❌  test-docustream-stack failed: Error: The stack named test-docustream-stack failed to deploy: CREATE_FAILED (Deployment failed)
    at waitForStackDeploy (/home/ianch/.nvm/versions/node/v14.15.0/pnpm-global/5/node_modules/.pnpm/[email protected]/node_modules/aws-cdk/lib/api/util/cloudformation.ts:309:11)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at prepareAndExecuteChangeSet (/home/ianch/.nvm/versions/node/v14.15.0/pnpm-global/5/node_modules/.pnpm/[email protected]/node_modules/aws-cdk/lib/api/deploy-stack.ts:355:26)
    at CdkToolkit.deploy (/home/ianch/.nvm/versions/node/v14.15.0/pnpm-global/5/node_modules/.pnpm/[email protected]/node_modules/aws-cdk/lib/cdk-toolkit.ts:208:24)
    at initCommandLine (/home/ianch/.nvm/versions/node/v14.15.0/pnpm-global/5/node_modules/.pnpm/[email protected]/node_modules/aws-cdk/lib/cli.ts:310:12)

The stack named test-docustream-stack failed to deploy: CREATE_FAILED (Deployment failed)

[dominikschubert]

Closing as this is unfortunately not directly related to cdklocal functionality. Changes to error reporting in comparison with default aws-cdk is out of scope of this project.

If there are specific CloudFormation status description etc. you'd expect in comparison with AWS please open an issue in localstack/localstack.

[iiian]

Yeah I was a bit worried you guys might just close it, but I do understand. So like specifically, when I used to run cdk deploy but something went wrong, like I had a leftover S3 bucket from a previous cdk deploy; cdk destroy (my environment refuses to delete S3 buckets via cloudformation, and I don't know if that's normal), I would get a nice, clear, big red error message that persisted in the console. It would very explicitly tell me "the S3 bucket 'my-s3-bucket' already exists, I can't create this stack for you." I've had similar things happen with other misconfigured resources, and that feedback mechanism had been incredibly helpful in trying to coordinate a functioning build. In contrast, cdklocal might display such information, although it is exceedingly ephemeral/volatile. It's there, and then it's gone, wiped away, even though cdk persists the same kind of information. Hopefully that's a vivid enough description. But I get it if that's not something you guys feel compelled to spend time on. Thanks for reading.