-
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
(core): exportValue fails on Intrinsics #19537
Labels
@aws-cdk/core
Related to core CDK functionality
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
needs-triage
This issue or PR still needs to be triaged.
p1
Comments
lxop
added
bug
This issue is a bug.
needs-triage
This issue or PR still needs to be triaged.
labels
Mar 24, 2022
rix0rrr
added a commit
that referenced
this issue
Apr 8, 2022
Number attributes go through two levels of encoding: - L1: because of lack of type information, all attributes are assumed to be `string`s, so we do `Token.asString(new CfnReference(...))`. - L2: we recast select attributes to numbers by doing `Token.asNumber()`. The end result is a Token that looks like: ```ts asNumber(Intrinsic(asString(CfnReference({ 'Fn::GetAtt': [...] })))) ``` When we do `Tokenization.reverse()` on the number, we only reverse the *first* encoding one layer, leaving us with an `Intrinsic` instead of the original `CfnReference`. `exportValue()` then rejects the value as not being the right type of token. Solution: before encoding, try to decode the given value so we always encode the innermost token, and not any of the inbetween ones. Fixes #19537.
mergify bot
pushed a commit
that referenced
this issue
Apr 8, 2022
Number attributes go through two levels of encoding: - L1: because of lack of type information, all attributes are assumed to be `string`s, so we do `Token.asString(new CfnReference(...))`. - L2: we recast select attributes to numbers by doing `Token.asNumber()`. The end result is a Token that looks like: ```ts asNumber(Intrinsic(asString(CfnReference({ 'Fn::GetAtt': [...] })))) ``` When we do `Tokenization.reverse()` on the number, we only reverse the *first* encoding one layer, leaving us with an `Intrinsic` instead of the original `CfnReference`. `exportValue()` then rejects the value as not being the right type of token. Solution: before encoding, try to decode the given value so we always encode the innermost token, and not any of the inbetween ones. Fixes #19537. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
otaviomacedo
pushed a commit
that referenced
this issue
Apr 11, 2022
Number attributes go through two levels of encoding: - L1: because of lack of type information, all attributes are assumed to be `string`s, so we do `Token.asString(new CfnReference(...))`. - L2: we recast select attributes to numbers by doing `Token.asNumber()`. The end result is a Token that looks like: ```ts asNumber(Intrinsic(asString(CfnReference({ 'Fn::GetAtt': [...] })))) ``` When we do `Tokenization.reverse()` on the number, we only reverse the *first* encoding one layer, leaving us with an `Intrinsic` instead of the original `CfnReference`. `exportValue()` then rejects the value as not being the right type of token. Solution: before encoding, try to decode the given value so we always encode the innermost token, and not any of the inbetween ones. Fixes #19537. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
StevePotter
pushed a commit
to StevePotter/aws-cdk
that referenced
this issue
Apr 27, 2022
Number attributes go through two levels of encoding: - L1: because of lack of type information, all attributes are assumed to be `string`s, so we do `Token.asString(new CfnReference(...))`. - L2: we recast select attributes to numbers by doing `Token.asNumber()`. The end result is a Token that looks like: ```ts asNumber(Intrinsic(asString(CfnReference({ 'Fn::GetAtt': [...] })))) ``` When we do `Tokenization.reverse()` on the number, we only reverse the *first* encoding one layer, leaving us with an `Intrinsic` instead of the original `CfnReference`. `exportValue()` then rejects the value as not being the right type of token. Solution: before encoding, try to decode the given value so we always encode the innermost token, and not any of the inbetween ones. Fixes aws#19537. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
We're facing this issue when trying to do
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/core
Related to core CDK functionality
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
needs-triage
This issue or PR still needs to be triaged.
p1
What is the problem?
When attempting to use
Stack.exportValue
to fix an inter-stack dependency, I found that it fails on the endpoint port of an RDS serverless cluster:It works well on the other attributes I needed, only this one fails to synthesise.
Reproduction Steps
What did you expect to happen?
The application should synthesise, and the cloudassembly should include exports for the cluster identifier, the secret ARN, and the cluster endpoint port.
What actually happened?
The application fails to synthesise with this error:
occurring on the line that exports the endpoint port.
CDK CLI Version
1.142.0 (build 5dd8e50)
Framework Version
No response
Node.js Version
v14.17.5
OS
OS X (Monterey)
Language
Python
Language Version
Python 3.8.12
Other information
From some experiments in the debugger, I've identified the source of the problem:
The
isReference()
response is false, because the port is not aReference
, it's anIntrinsic
. Skipping this check and carrying on with the rest of the logic worked just fine, so I'm not sure if the check simply needs to be changed to also acceptIntrinsic
s or whether there is something special about thisport
attribute compared to otherIntrinsic
s.The text was updated successfully, but these errors were encountered: