Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Token.toNumber fails with Tcp/UdpPort after the ...FromAttribute versions were removed #2679

Closed
Labels
bug This issue is a bug.

Comments

@brad-jones
Copy link

Describe the bug
After this was merged #2580 I now see errors like this:

(node:22) UnhandledPromiseRejectionWarning: Error: Token value is not number or lazy, can't represent as number: ${Token[DBCluster.Endpoint.Port.199]}
    at Token.toNumber (/app/node_modules/.registry.npmjs.org/@aws-cdk/cdk/0.32.0/node_modules/@aws-cdk/cdk/lib/token.ts:162:15)
    at new PostgreSQLDb (/app/context/nbnsq-infra/constructs/PostgreSQLDb.ts:92:52)
    at new NbnSq (/app/context/nbnsq-infra/stacks/NbnSq.ts:354:17)
    at /app/context/nbnsq-infra/app.ts:137:2

To Reproduce

const sg = new SecurityGroup(this, "SecurityGroup", {...});
const cluster = new CfnDBCluster(this, "DBCluster", {...});
sg.addIngressRule(
    new CidrIPv4('127.0.0.1/32'),
    new TcpPort(new Token(cluster.dbClusterEndpointPort).toNumber())
);

Expected behavior
TcpPort to accept the Token after being converted with toNumber as outlined in the v0.32.0 change log: "ec2.TcpPortFromAttribute and UdpPortFromAttribute removed. Use TcpPort and UdpPort with new Token(x).toNumber instead."

Work around
This still produces a working template.

const sg = new SecurityGroup(this, "SecurityGroup", {...});
const cluster = new CfnDBCluster(this, "DBCluster", {...});
sg.addIngressRule(
    new CidrIPv4('127.0.0.1/32'),
    cluster.dbClusterEndpointPort as any as number
);

Version:

  • Programming Language: Typescript
  • CDK Version: 0.32.0
@brad-jones brad-jones added the bug This issue is a bug. label May 30, 2019
eladb pushed a commit that referenced this issue May 30, 2019
relax restrictions on input types for Token.toXxx in order to allow
flexible type coercion.

this may be needed in situations where users want to force a token
typed as one type to be represented as another type and generally
allow tokens to be used as "type-system escape hatches".

Previously, this did not work:

    const port = new Token({ "Fn::GetAtt": [ "ResourceId", "Port" ] }).toString(); 
    new TcpPort(new Token(port).toNumber());

Also, this did not work:

    const port = new Token({ "Fn::GetAtt": [ "ResourceId", "Port" ]}).toNumber();

Fixes #2679
eladb pushed a commit that referenced this issue Jun 2, 2019
Relax restrictions on input types for Token.toXxx in order to allow flexible type coercion.

This may be needed in situations where users want to force a token typed as one type to be represented as another type and generally allow tokens to be used as "type-system escape hatches".

Previously, this did not work:

    const port = new Token({ "Fn::GetAtt": [ "ResourceId", "Port" ] }).toString(); 
    new TcpPort(new Token(port).toNumber());

Also, this did not work:

    const port = new Token({ "Fn::GetAtt": [ "ResourceId", "Port" ]}).toNumber();

These were just examples. The point is that if a user reached the point where you actually need a token, they basically indicate to the framework that “I know what I am are doing”. It’s a sort of an “as any” at the framework level.

Fixes #2679
This was referenced Dec 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment