Validate that the workflow payload is correct

[agrare]

part of: #130

Rules from ASL spec https://states-language.net/

Top-level fields

• [x] A State Machine MUST have an object field named "States", whose fields represent the states.
• [x] A State Machine MUST have a string field named "StartAt", whose value MUST exactly match one of names of the "States" fields. The interpreter starts running the the machine at the named state.

States

• [x] The state name, whose length MUST BE less than or equal to 80 Unicode characters, is the field name
• [x] State names MUST be unique within the scope of the whole state machine. (NOTE JSON.parse() only returns the last entry)
• [x] All states MUST have a "Type" field. This document refers to the values of this field as a state’s type, and to a state such as the one in the example above as a Task State.
• [x] Any state except for Choice, Succeed, and Fail MAY have a field named "End" whose value MUST be a boolean. The term "Terminal State" means a state with with { "End": true }, or a state with { "Type": "Succeed" }, or a state with { "Type": "Fail" }.

Transitions

• [x] All non-terminal states MUST have a "Next" field, except for the Choice State. The value of the "Next" field MUST exactly and case-sensitively match the name of another state.
• [x] Choice "Default" MUST match the name of another state.
• [x] Choice Choices MUST have a "Next" field that MUST match the name of another state.

Timestamps

• [ ] These are strings which MUST conform to the RFC3339 profile of ISO 8601, with the further restrictions that an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset, for example "2016-03-14T01:59:00Z".

Data

• [ ] The interpreter passes data between states to perform calculations or to dynamically control the state machine’s flow. All such data MUST be expressed in JSON.
• [ ] As each state is executed, it receives a JSON text as input and can produce arbitrary output, which MUST be a JSON text.

Reference Paths

• [ ] all Reference Paths MUST be unambiguous references to a single value, array, or object (subtree).

Payload Template

• [ ] A Payload Template MUST be a JSON object; it has no required fields. (I believe this is covered already)
• [x] If the field value begins with only one "$", the value MUST be a Path.
• [x] If the field value begins with "$$", the first dollar sign is stripped and the remainder MUST be a Path
• [ ] If the field value does not begin with "$", it MUST be an Intrinsic Function (see below)
• [ ] A JSON object MUST NOT have duplicate field names after fields ending with the characters ".$" are renamed to strip the ".$" suffix. (I believe this is covered already)

Intrinsic Functions

• [ ] An Intrinsic Function MUST be a string.
• [ ] The Intrinsic Function MUST begin with an Intrinsic Function name.
• [ ] An Intrinsic Function name MUST contain only the characters A through Z, a through z, 0 through 9, ".", and "_".
• [ ] The Intrinsic Function name MUST be followed immediately by a list of zero or more arguments, enclosed by "(" and ")", and separated by commas.
• [ ] Intrinsic Function arguments may be strings enclosed by apostrophe (') characters, numbers, null, Paths, or nested Intrinsic Functions.
• [ ] The following characters are reserved for all Intrinsic Functions and MUST be escaped: ' { } \

There are more...

https://github.com/ManageIQ/floe/issues/130

[kbrock]

Why is this WIP? This is a beauty and needs to get merged stat ;)

Maybe we should move the criteria into the parent issue? and add check boxes? Also noticed (in AWS specs) that some of the specs are across all states, and others are state specific. Maybe we can separate these 2 concepts so it is easier to follow?

[agrare]

Why is this WIP? Maybe we should move the criteria into the parent issue? and add check boxes?

Yes I was seeing how far I could get through all of the rules but I think this is in a pretty good spot, I'll move the list to the parent issue and take this out of WIP

[agrare]

Okay I wanted to get the Next state checks for Choice done, have added that now

[Fryguy]

Are there any ordering issues here? That is, are the states validated as they are being processed, and if so, could a state defined after a reference to it cause issues? For example, I see the Choice state validates the "Default", but what if the Default state is defined after the Choice state. I feel like that is a common layout and would have been caught in specs, but the way I'm reading the code, it feels like it could still happen?

[agrare]

That's why we're validating the payload rather than the parsed states objects when checking for things like "does Default exist in States"

[Fryguy]

Oh I see, so for https://github.com/ManageIQ/floe/pull/136/files#diff-76feb017cc942fa02bf72a61cb066c70342a42039ace6610b861b9de0a5463a9R52, the payload of the higher order workflow is already parsed and validated at this point.

Thanks :+1:

[Fryguy]

super-super-minor, but it makes me wonder if the method should be named validate_payload to make it clear we are validating against the raw payload.

[agrare]

but it makes me wonder if the method should be named validate_payload to make it clear we are validating against the raw payload.

Possibly? I was thinking there could be a number of things that we are validating and the raw payload is just one of them though

[miq-bot]

Checked commit https://github.com/agrare/floe/commit/8b0590d5a04036624090edb2c8717e3bc26f42ba with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint 14 files checked, 0 offenses detected Everything looks fine. :+1: