-
Notifications
You must be signed in to change notification settings - Fork 4k
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-events] concatenating event fields should produce an error #9191
Comments
Yeah... this kind of thing you cannot do in step functions. You're basically asking event bridge to do is to concatenate strings in json and this cannot be done. It's got nothing to do with cdk - it's an event bridge issue. Try this:
|
Sure, I've figured that much out in the meantime and agree that it cannot be done. With that in mind, should there be a in-library measure against this behavior? Should the CDK allow this to compile when it obviously results in strange wrapping tokens? I think the CDK ought to detect this and raise an appropriate warning. |
Event Bridge has been updated to support string formatting in a json object. https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html "InputTransformer":
{
"InputPathsMap": {"instance": "$.detail.instance","status": "$.detail.status"},
"InputTemplate": "<instance> is in state <status>"
} "InputTransformer":
{
"InputPathsMap": {"instance": "$.detail.instance","status": "$.detail.status"},
"InputTemplate": "<instance> is in state \"<status>\""
} We would expect something like this to work now RuleTargetInput.fromObject({
data: `some text ${EventField.fromPath('$')}`
}) |
Event Bridge transformers have been updated to support embedded variable replacement within strings within objects. ``` { data: "some string <myValue>" } ``` Previously input transformers only supported string when they were the only value of an object, or just static strings. ``` // Before Event Bridges's change { data: <myValue>, // OK data2: "some string", // OK data3: "some string <myValue>" // NOT OK } ``` The CDK solution was to assume that developers knew this restriction, wrap the string variable in special characters, and replace the double quotes plus special character set with nothing after token replacement. This caused issues like #9191. Where string tokens (`EventField`) within a string would give a cryptic error during Cfn deployment due the resulting invalid object string generated (missing a closing double quote and leaving the special characters behind). ### Solution: Removed the special character sequence addition and stripping and instead only replace any instances of `"<myValue>"` that are added. * Iterate over the known input transform keys to reduce possible unexpected impact and give developers a backdoor to change their keys in the worst case. * Edge Case: `"<myValue>"` can appear with escaped quote sequences `"something \"quoted\"<myValue>"`. This is a valid string variable replacement case. Used a lookback regex (`(?<!\\\\)\"\<${key}\>\"`) to avoid the prefix escaped quote when replacing transform input keys with quote-less keys. ### Tradeoffs Removed the addition of special characters to find the keys in the final json string. Instead search for the specific pattern of transform input keys that should exist within the output and handle the edge case describe above. This SHOULD cover all edge cases as it is not valid to have a trailing quote without an escape (`"<myValue>"" //not valid`) and it is not valid to have a prefix quote that is not escaped (`""<myValue>" // not valid`). This was done to reduce the small change of overlapping with a developer's content, to be more targeted, and because the above should prove that the edge case is covered. https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html fixes #9191 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Event Bridge transformers have been updated to support embedded variable replacement within strings within objects. ``` { data: "some string <myValue>" } ``` Previously input transformers only supported string when they were the only value of an object, or just static strings. ``` // Before Event Bridges's change { data: <myValue>, // OK data2: "some string", // OK data3: "some string <myValue>" // NOT OK } ``` The CDK solution was to assume that developers knew this restriction, wrap the string variable in special characters, and replace the double quotes plus special character set with nothing after token replacement. This caused issues like aws#9191. Where string tokens (`EventField`) within a string would give a cryptic error during Cfn deployment due the resulting invalid object string generated (missing a closing double quote and leaving the special characters behind). ### Solution: Removed the special character sequence addition and stripping and instead only replace any instances of `"<myValue>"` that are added. * Iterate over the known input transform keys to reduce possible unexpected impact and give developers a backdoor to change their keys in the worst case. * Edge Case: `"<myValue>"` can appear with escaped quote sequences `"something \"quoted\"<myValue>"`. This is a valid string variable replacement case. Used a lookback regex (`(?<!\\\\)\"\<${key}\>\"`) to avoid the prefix escaped quote when replacing transform input keys with quote-less keys. ### Tradeoffs Removed the addition of special characters to find the keys in the final json string. Instead search for the specific pattern of transform input keys that should exist within the output and handle the edge case describe above. This SHOULD cover all edge cases as it is not valid to have a trailing quote without an escape (`"<myValue>"" //not valid`) and it is not valid to have a prefix quote that is not escaped (`""<myValue>" // not valid`). This was done to reduce the small change of overlapping with a developer's content, to be more targeted, and because the above should prove that the edge case is covered. https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_InputTransformer.html fixes aws#9191 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Creating an input transformer for a Cloudwatch Rule results in questionable syntax in the Cloudformation output causing the stack to unsuccessfully deploy.
Reproduction Steps
This results in CFN output where I've trimmed some of the irrelevant parts:
I'm expecting
InputTemplate: '{"name":"testing_at_<time>}'
. My question is, am I building this correctly or is this a bug?Error Log
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: