TypeError: Cannot read property 'Symbol(@aws-cdk/core.DependableTrait)' of undefined

General Issue

TypeError: Cannot read property ‘Symbol(@aws-cdk/core.DependableTrait)’ of undefined

The Question

Hello,

After migrating my CDK v1 project to v2, and using the “constructs” library, a new issue popped up making it unable to deploy a CDK app:

MyProject/cdk/node_modules/constructs/src/dependency.ts:48
    const ret = (instance as any)[DEPENDABLE_SYMBOL];
                                 ^
TypeError: Cannot read property 'Symbol(@aws-cdk/core.DependableTrait)' of undefined
    at Function.of (MyProject/cdk/node_modules/constructs/src/dependency.ts:48:34)
    at Node.get dependencies [as dependencies] (MyProject/cdk/node_modules/constructs/src/construct.ts:201:37)
    at findTransitiveDeps (MyProject/cdk/node_modules/aws-cdk-lib/core/lib/private/prepare-app.ts:114:42)
    at Object.prepareApp (MyProject/cdk/node_modules/aws-cdk-lib/core/lib/private/prepare-app.ts:19:28)
    at Object.synthesize (MyProject/cdk/node_modules/aws-cdk-lib/core/lib/private/synthesis.ts:32:3)
    at App.synth (MyProject/cdk/node_modules/aws-cdk-lib/core/lib/stage.ts:90:23)
    at process.<anonymous> MyProject/cdk/node_modules/aws-cdk-lib/core/lib/app.ts:64:45)
    at Object.onceWrapper (node:events:514:26)
    at process.emit (node:events:394:28)
    at process.emit (node:domain:470:12)

My package.json file:

{
  "name": "cdk",
  "version": "0.1.0",
  "bin": {
    "cdk": "bin/cdk.js"
  },
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "jest",
    "cdk": "cdk"
  },
  "devDependencies": {
    "@aws-cdk/assert": "^2.10.0",
    "@types/aws-lambda": "^8.10.92",
    "@types/jest": "^27.4.0",
    "@types/node": "^17.0.14",
    "aws-cdk": "^2.10.0",
    "jest": "^27.4.7",
    "ts-jest": "^27.1.3",
    "ts-node": "^10.4.0",
    "typescript": "~4.5.5"
  },
  "dependencies": {
    "@aws-cdk/aws-apigatewayv2-alpha": "^2.10.0-alpha.0",
    "@aws-cdk/aws-apigatewayv2-authorizers-alpha": "^2.10.0-alpha.0",
    "@aws-cdk/aws-apigatewayv2-integrations-alpha": "^2.10.0-alpha.0",
    "@aws-sdk/client-cloudwatch-logs": "^3.45.0",
    "@aws-sdk/client-dynamodb": "^3.45.0",
    "@aws-sdk/client-ec2": "^3.45.0",
    "@aws-sdk/client-emr": "^3.45.0",
    "@aws-sdk/client-eventbridge": "^3.45.0",
    "@aws-sdk/client-lambda": "^3.45.0",
    "@aws-sdk/client-s3": "^3.45.0",
    "@aws-sdk/client-sfn": "^3.45.0",
    "@aws-sdk/client-sts": "^3.45.0",
    "@slack/web-api": "^6.5.1",
    "aws-cdk-lib": "^2.10.0",
    "cdk": "^2.10.0",
    "constructs": "^10.0.51",
    "npm-check-updates": "^12.1.0",
    "short-uuid": "^4.2.0",
    "source-map-support": "^0.5.21"
  }
}

I also installed the legacy @aws-cdk/core but it didn’t help, as it seems that the constructs library fails on this line:

DependencyGroup[_a] = { fqn: "constructs.DependencyGroup", version: "10.0.51" };
const DEPENDABLE_SYMBOL = Symbol.for('@aws-cdk/core.DependableTrait');

Any ideas? Thank you

CDK CLI Version

2.10.0 (build e5b301f)

Framework Version

No response

Node.js Version

v16.3.0

OS

MacOS

Language

Typescript

Language Version

4.5.5

Other information

No response

[joequincy]

Commenting for future people searching about this error. This may not be the exact problem OP had, but it presented with the same error message from the issue title. So if you’re running into that error, this may help.

I had a very nearly identical problem crop up following the upgrade to 2.39.0:

NODE_ENV=staging yarn cdk deploy <stack-name> --require-approval never
yarn run v1.22.19
$ /home/runner/work/repo-name/repo-name/node_modules/.bin/cdk deploy <stack-name> --require-approval never
/home/runner/work/repo-name/repo-name/node_modules/constructs/src/dependency.ts:91
    const ret = (instance as any)[DEPENDABLE_SYMBOL];
                                 ^
TypeError: Cannot read property 'Symbol(@aws-cdk/core.DependableTrait)' of undefined
    at Function.of (/home/runner/work/repo-name/repo-name/node_modules/constructs/src/dependency.ts:91:34)
    at Object.get dependencyRoots [as dependencyRoots] (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/aws-ec2/lib/vpc.js:1:27169)
    at Node.get dependencies [as dependencies] (/home/runner/work/repo-name/repo-name/node_modules/constructs/src/construct.ts:317:44)
    at findTransitiveDeps (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/core/lib/private/prepare-app.js:1:1434)
    at Object.prepareApp (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/core/lib/private/prepare-app.js:1:309)
    at Object.synthesize (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/core/lib/private/synthesis.js:1:557)
    at App.synth (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/core/lib/stage.js:1:1866)
    at process.<anonymous> (/home/runner/work/repo-name/repo-name/node_modules/aws-cdk-lib/core/lib/app.js:1:1164)
    at Object.onceWrapper (events.js:520:26)
    at process.emit (events.js:400:28)

Subprocess exited with error 1
error Command failed with exit code 1.

This ultimately turned out to be caused because we had been using CDK in a way that worked but was undefined and unsupported. We have a lambda which needs explicitly defined subnets, for which we know the Subnet IDs.

For this, we had been using plain objects like:

lambda.Function(this, 'some-lambda-id', {
  ...
  vpcSubnets: {
    subnets: [
      { subnetId: 'someId' },
    ],
  },
})

This bit us when changes in 2.39.0 added checks that rely on certain nested properties of Subnets. Since we only had the subnetId property, accessing these nested properties failed

Cannot read property 'Symbol(@aws-cdk/core.DependableTrait)' of undefined

tl;dr

The fix was to use the appropriate method (in this case ec2.Subnet.fromSubnetId) to construct objects that properly implement the appropriate interface… instead of creating raw objects that only implement a minimal subset of properties that happen to work for now.

(this may seem like an obvious one to some folks… but if I can save someone else the afternoon I spent debugging this in my codebase, I’ll eat the embarrassment)

[peterwoodworth]

Ah interesting, I wonder why that was. I’m glad you got it figured out 🙂