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

fix(core): exportValue does not work on number attributes #19818

Merged
merged 3 commits into from
Apr 8, 2022

Conversation

rix0rrr
Copy link
Contributor

@rix0rrr rix0rrr commented Apr 8, 2022

Number attributes go through two levels of encoding:

  • L1: because of lack of type information, all attributes are assumed to
    be strings, 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:

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

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.
@rix0rrr rix0rrr requested a review from a team April 8, 2022 08:55
@rix0rrr rix0rrr self-assigned this Apr 8, 2022
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Apr 8, 2022
@gitpod-io
Copy link

gitpod-io bot commented Apr 8, 2022

@aws-cdk-automation aws-cdk-automation requested a review from a team April 8, 2022 08:55
@github-actions github-actions bot added bug This issue is a bug. effort/small Small work item – less than a day of effort p1 labels Apr 8, 2022
@mergify
Copy link
Contributor

mergify bot commented Apr 8, 2022

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: 00cfcf3
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit 12459ca into master Apr 8, 2022
@mergify mergify bot deleted the huijbers/exportvalue branch April 8, 2022 11:31
@mergify
Copy link
Contributor

mergify bot commented Apr 8, 2022

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

otaviomacedo pushed a commit that referenced this pull request 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 pull request 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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. contribution/core This is a PR that came from AWS. effort/small Small work item – less than a day of effort p1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

(core): exportValue fails on Intrinsics
3 participants