fix(stepfunctions): renderObject ignores explicit null

[kaizencc]

Fixes #16253.

The stepfunctions module has a function renderObject that deep renders a JSON object to expand JSON path fields. Previously, renderObject handled null values and undefined values the same. However, null and undefined have different meanings in Typescript and it is possible for a user to want to pass an explicit null into the JSON path. For example:

FieldUtils.renderObject({
  reference1: {nullParameter: null},
  reference2: {notNullParameter: 'not null'},
})

Previously would result in:

{
  reference2: {notNullParameter: 'not null'}
}

which completely ignores the null parameter. Now, this results in:

{
  reference1: {nullParameter: null},
  reference2: {notNullParameter: 'not null'}
}

which is the expected behavior.

This PR builds on what was started in #16721.

---

There is also a bug (I believe) in how we specify notificationProperty for GlueStartJobRun and RunGlueJobTask in aws-stepfunctions-tasks. The default value is specified as null and not undefined, which I think is typically how we specify non-existent properties in Typescript.

❗ I am not sure if notificationProperty is some sort of exception to this rule ❗, but I have looked at the documentation for it and nothing seems to suggest that the null value was intentional. It was introduced in this PR as well as this one.

---

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

[gitpod-io]

[rix0rrr]

However, null and undefined have different meanings in Typescript and it is possible for a user to want to pass an explicit null into the JSON path.

Yes but no. There is a difference between null and undefined in JavaScript, but there is not a difference between them in jsii (because Java does not have this distinction, Python does not have this distinction, etc).

So we can not rely on the fact that they are two different values in our TypeScript code.

The only correct way to deal with this is to change the API in such a way that the user has another ability to specify a null (maybe an additional property, maybe a magic value) -- and it would be better to name it after the effect of specifying a null, something like DROP_STATE or something (not necessarily a great name, but I just want to indicate that it shouldn't be SPECIFY_NULL: that doesn't tell anybody anything).

[kaizencc]

Sounds like a plan. I'm actually going to p2 this fix and leave it hanging for now. It doesn't really seem like that big of a miss now that the limitations are explained. I might circle back to it if it seems like more customers are providing +1's to the original issue: #16253.

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[krish00back]

I am facing this issue.