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

(@aws-cdk/aws-events-targets module): Falsely detect change to Chinese text string #13634

Closed
tamakisquare opened this issue Mar 17, 2021 · 3 comments · Fixed by #25912
Closed
Assignees
Labels
@aws-cdk/aws-events-targets blocked Work is blocked on this issue for this codebase. Other labels or comments may indicate why. bug This issue is a bug. effort/small Small work item – less than a day of effort needs-cfn This issue is waiting on changes to CloudFormation before it can be addressed. needs-triage This issue or PR still needs to be triaged. p1

Comments

@tamakisquare
Copy link

tamakisquare commented Mar 17, 2021

CDK CLI falsely detects a change to Chinese characters when there's no change at all.

The Chinese characters are passed into the constructor of Lambda function invoking event rule target as the event object.

Reproduction Steps

new Rule(this, 'MonthlyReminder', {
  enabled: true,
  schedule: Schedule.cron({ day: '1', hour: '0', minute: '0' }),
  targets: [
    new LambdaFunction(sendReminderFn, {
      event: RuleTargetInput.fromObject({ message: '今日五號,請交月報。' }),
    }),
  ],
});

What did you expect to happen?

CDK CLI should know there's no change.

What actually happened?

CDK CLI falsely recognizes there's a change to the Chinese text string. Somehow, CDK CLI shows the current version of the text as a series of question marks "????".
Screen Shot 2021-03-17 at 4 40 27 PM

Environment

  • CDK CLI Version : 1.93
  • Framework Version: 1.93
  • Node.js Version: 14.6
  • OS : MacOS 10.15.7
  • Language (Version): TypeScript (4.1.2)

Other


This is 🐛 Bug Report

@tamakisquare tamakisquare added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Mar 17, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Mar 17, 2021

Unfortunately this is a bug in CloudFormation, and the CDK cannot do anything about this.

I've created an issue for you in their public bug tracker: aws-cloudformation/cloudformation-coverage-roadmap#814

Please go upvote that there, or ask your AWS support contact to escalate the issue internally.

@rix0rrr rix0rrr added blocked Work is blocked on this issue for this codebase. Other labels or comments may indicate why. effort/small Small work item – less than a day of effort needs-cfn This issue is waiting on changes to CloudFormation before it can be addressed. p1 labels Mar 17, 2021
@tamakisquare
Copy link
Author

Thanks @rix0rrr. It's good to know the source of the issue.

@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

mergify bot pushed a commit that referenced this issue Jun 15, 2023
I am reopening this from #25525

and following up on my comments here:
#24557 (comment)
#24557 (comment)
#25008 (comment)
#25008 (comment)
#25008 (comment)
#25008 (comment)
#25008 (comment)
#25008 (comment)
#25525 (comment)
#25525 (comment)
🫠 #25525 (comment) 🫠

---

Fixes #25309
Fixes #22203
Fixes #20212
Fixes #13634
Fixes #10523
Fixes #10219
See also: aws-cloudformation/cloudformation-coverage-roadmap#1220
See also: aws-cloudformation/cloudformation-coverage-roadmap#814

---

👻 I have retitled this PR as a `chore` instead of a `fix` because @aws-cdk-automation keeps closing my PRs as abandoned even though they are clearly not abandoned.

> This PR has been deemed to be abandoned, and will be automatically closed. Please create a new PR for these changes if you think this decision has been made in error.

---

@otaviomacedo @rix0rrr @TheRealAmazonKendra - I'm happy to adjust the approach, add more tests, or do what else needs to be done. I'm not getting any feedback from the team so I'm not sure how to proceed. The diff noise with non-ASCII information in cdk diff makes it difficult to find meaningful changes to our stacks.

🗿🗞️📬 **Crucially, this change only affects the CLI output and therefore an integration test isn't possible.**

---

CloudFormation's `GetStackTemplate` irrecoverably mangles any character not in the 7-bit ASCII range. This causes noisy output from `cdk diff` when a template contains non-English languages or emoji. We can detect this case and consider these strings equal.

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*

Many AWS services accept non-ASCII input, eg many "description" fields. CloudFormation will correctly dispatch these templates but when invoking `GetStackTemplate` the result is mangled. This causes annoying noise in the output of `cdk diff`:

```
Resources
[~] AWS::Lambda::Function Lambda/Resource
 └─ [~] Description
     ├─ [-] ?????
     └─ [+] 🤦🏻‍♂️
```

This change modifies the diff algorithm to consider the string equal if the lvalue is a mangled version of the rvalue.

Of course this runs the risk of hiding changesets which modify only a single non-ASCII character to another non-ASCII character, but these fields already tend to be informative in nature.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/aws-events-targets blocked Work is blocked on this issue for this codebase. Other labels or comments may indicate why. bug This issue is a bug. effort/small Small work item – less than a day of effort needs-cfn This issue is waiting on changes to CloudFormation before it can be addressed. needs-triage This issue or PR still needs to be triaged. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants