There are currently failing contract tests due to some properties not being present in the model returned from the Read handler.
There are some properties that are present in the CloudFormation resource model that are not part of the Step Functions resource model, specifically Definition, DefinitionS3Location, and DefinitionSubstitutions. Since these properties are not part of the Step Functions resource model, they will not be included in the DescribeStateMachine and ListTagsForResource responses in the Read handler. There are two options to address this failing test:
Copy the property from the model provided in the handler request to the model provided in the handler response. This gets a bit tricky though as we could potentially have a Definition property provided in the handler request and a DefinitionString returned in the DescribeStateMachine response, which currently gets copied to the updated model. This model would be considered invalid, as only one of Definition, DefinitionS3Location, and DefinitionString should be specified.
[Selected] Mark the Definition, DefinitionS3Location, and DefinitionSubstitutions as writeOnlyProperties, meaning that they can be specified, but will not be provided in a response from the Read or List handlers. This addresses the failing contract tests and still returns a valid model from the Read handler.
Open thoughts
I am not sure how this will work with drift detection, as we are potentially changing the properties defined in the resource model. The purpose of the Read handler is to capture the current state of the resource, meaning the output model should contain properties determined from calling read APIs. The other approach directly copies the property from the request to the response model, which doesn't actually confirm if there is any resource drift.
Testing
mvn package
Ran contract tests using cfn test --enforce-timeout 240
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Description of changes:
There are currently failing contract tests due to some properties not being present in the model returned from the Read handler.
There are some properties that are present in the CloudFormation resource model that are not part of the Step Functions resource model, specifically
Definition,DefinitionS3Location, andDefinitionSubstitutions. Since these properties are not part of the Step Functions resource model, they will not be included in theDescribeStateMachineandListTagsForResourceresponses in the Read handler. There are two options to address this failing test:Definitionproperty provided in the handler request and a DefinitionString returned in theDescribeStateMachineresponse, which currently gets copied to the updated model. This model would be considered invalid, as only one ofDefinition,DefinitionS3Location, andDefinitionStringshould be specified.Definition,DefinitionS3Location, andDefinitionSubstitutionsas writeOnlyProperties, meaning that they can be specified, but will not be provided in a response from the Read or List handlers. This addresses the failing contract tests and still returns a valid model from the Read handler.Open thoughts
I am not sure how this will work with drift detection, as we are potentially changing the properties defined in the resource model. The purpose of the Read handler is to capture the current state of the resource, meaning the output model should contain properties determined from calling read APIs. The other approach directly copies the property from the request to the response model, which doesn't actually confirm if there is any resource drift.
Testing
mvn packagecfn test --enforce-timeout 240By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.