-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
brad-jones opened this issue
May 30, 2019
· 0 comments
· Fixed by #2680 or MechanicalRock/tech-radar#14 · May be fixed by MechanicalRock/cdk-constructs#5, MechanicalRock/cdk-constructs#6 or MechanicalRock/cdk-constructs#7
Closed
Token.toNumber fails with Tcp/UdpPort after the ...FromAttribute versions were removed #2679
brad-jones opened this issue
May 30, 2019
· 0 comments
· Fixed by #2680 or MechanicalRock/tech-radar#14 · May be fixed by MechanicalRock/cdk-constructs#5, MechanicalRock/cdk-constructs#6 or MechanicalRock/cdk-constructs#7
Labels
bug
This issue is a bug.
Comments
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 Aug 22, 2019
This was referenced Dec 12, 2019
This was referenced Jan 20, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
After this was merged #2580 I now see errors like this:
To Reproduce
Expected behavior
TcpPort
to accept theToken
after being converted withtoNumber
as outlined in thev0.32.0
change log: "ec2.TcpPortFromAttribute
andUdpPortFromAttribute
removed. UseTcpPort
andUdpPort
withnew Token(x).toNumber
instead."Work around
This still produces a working template.
Version:
The text was updated successfully, but these errors were encountered: