Unable to deploy after upgrade cdk version

[mouyigang]

I deployed my stack(cdk 0.20.0) then upgrade cdk to 0.21.0 and it started to complain about uniqueid?
Can't destroy either, same err.

Should I downgrade, destroy and deploy again?

cdk deploy
mycdkcdk/node_modules/@aws-cdk/cdk/lib/util/uniqueid.js:36
        throw new Error(`ID components may not include unresolved tokens: ${unresolvedTokens.join(',')}`);
        ^

Error: ID components may not include unresolved tokens: ${Token[chromeecrF215BE5B.Ref.278]}
    at Object.makeUniqueId (mycdkcdk/node_modules/@aws-cdk/cdk/lib/util/uniqueid.js:36:15)
    at new Construct (mycdkcdk/node_modules/@aws-cdk/cdk/lib/core/construct.js:53:60)
    at new ContainerDefinition (mycdkcdk/node_modules/@aws-cdk/aws-ecs/lib/container-definition.js:11:9)
    at FargateTaskDefinition.addContainer (mycdkcdk/node_modules/@aws-cdk/aws-ecs/lib/base/task-definition.js:82:27)
    at projects.nodes.forEach.project (mycdkcdk/lib/fargateService.js:48:28)
    at Array.forEach (<anonymous>)
    at Object.exports.create_fargate_service (mycdkcdk/lib/fargateService.js:46:20)
    at new SeleniumgridcdkStack (mycdkcdk/lib/seleniumgridcdk-stack.js:44:26)
    at Object.<anonymous> (mycdkcdk/bin/seleniumgridcdk.js:7:1)
    at Module._compile (internal/modules/cjs/loader.js:688:30)

Code:

   projects.nodes.forEach(project => {
        if (project.ecr) {
            fargateTaskdef.addContainer(project.ecr.repositoryName, {
                image: ContainerImage.fromEcrRepository(project.ecr, 'latest'),
                essential: true,
                healthCheck: {command: [`curl -f http://localhost:${nodeport}/ || exit 1`]},
                environment: {
                CHROME_VERSION: project.browser_name || "general",
                HUB_PORT_4444_TCP_ADDR: "localhost",
                HUB_PORT_4444_TCP_PORT: `${hubport}`,
                NODE_PORT: `${nodeport}`,
                SE_OPTS: `-host 0.0.0.0 -port ${nodeport}`
                }
            });
            nodeport += 1;
        }
    });

[eladb]

Hi @mouyigang, this is because you are using project.ecr.repositoryNameas the first argument to addContainer and this value can only be resolved at deploy-time. Therefore, it cannot be used as an ID for a construct, and we have added a check in v0.21.0 to ensure that people don't accidentally use those lazy-resolved tokens for IDs. As you can see from the error, the actual value passed in for the ID is ${Token[chromeecrF215BE5B.Ref.278]} which is essentially a "promise" for a value that will only be available during deployment.

Ideally, for IDs you probably want to use concrete strings that are "stable" and represent the static structure of your infrastructure.

@rix0rrr, I am wondering if we should use some naming convention for these IDs (e.g. cid or conid) so it will be more intuitive to people that these have some special meaning. Thoughts?

[mouyigang]

It's not a big problem but would be nice to pass the build check if I actually specified repositoryName for the project.ecr.

I haven't checked but since it can work out duplicate names at build time, this would not be a problem to figure out I suppose.

Anyway, thanks for the explanation.

Hi @mouyigang, this is because you are using project.ecr.repositoryNameas the first argument to addContainer and this value can only be resolved at deploy-time. Therefore, it cannot be used as an ID for a construct, and we have added a check in v0.21.0 to ensure that people don't accidentally use those lazy-resolved tokens for IDs. As you can see from the error, the actual value passed in for the ID is ${Token[chromeecrF215BE5B.Ref.278]} which is essentially a "promise" for a value that will only be available during deployment.

Ideally, for IDs you probably want to use concrete strings that are "stable" and represent the static structure of your infrastructure.

@rix0rrr, I am wondering if we should use some naming convention for these IDs (e.g. cid or conid) so it will be more intuitive to people that these have some special meaning. Thoughts?