Validate that state machine input is valid JSON

[agrare]

When running a workflow validate that the state-machine input is valid JSON. We were a little lax with specs passing Hashes in for convenience but it isn't hard to ensure we're passing JSON in to context input.

When running with ASL passing invalid input:

$ aws stepfunctions --endpoint-url http://localhost:8083 start-execution --state-machine-arn arn:aws:states:us-east-1:123456789012:stateMachine:Pass --input 'foo'

An error occurred (InvalidExecutionInput) when calling the StartExecution operation: Invalid State Machine Execution Input: 'Unrecognized token 'foo': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')
 at [Source: (String)"foo"; line: 1, column: 4]'

With this PR:

$ exe/floe examples/workflow.asl 'foo'
Invalid State Machine Execution Input: unexpected token at 'foo': was expecting (JSON String, Number, Array, Object or token 'null', 'true' or 'false')

[Fryguy]

I like how it matches the simulator 👍

[kbrock]

Like how the if input... has been removed.

Would prefer to change the default input: "{}" and drop the input || "{}"

[agrare]

the input ||= {} was if someone explicitly passed :input => nil it would still default to {} and that still applies

[kbrock]

Heh. Yea.

I guess in general I want to keep the data closer to what the user provided.

[agrare]

I think the better question is "what does step functions do?", if I do

aws stepfunctions start-execution --input "null"

I get "null" output

{
    "executionArn": "arn:aws:states:us-east-1:123456789012:execution:Succeed:6cae58d1-1aa6-415f-a010-ddc730d6b81f",
    "stateMachineArn": "arn:aws:states:us-east-1:123456789012:stateMachine:Succeed",
    "name": "6cae58d1-1aa6-415f-a010-ddc730d6b81f",
    "status": "SUCCEEDED",
    "startDate": "2024-06-24T14:50:47.849000-04:00",
    "stopDate": "2024-06-24T14:50:47.876000-04:00",
    "input": "null",
    "inputDetails": {
        "included": true
    },
    "output": "null",
    "outputDetails": {
        "included": true
    }
}

So I think actually {} if not provided, but nil if explicitly passed "null" is actually correct.

[kbrock]

I think we are in total agreement here.

(I was just squabbling over who converted a nil => {} / "null" => nil, and was thinking it was the cli. But not my hill)

[agrare]

(I was just squabbling over who converted a nil => {} / "null" => nil, and was thinking it was the cli. But not my hill)

Hey I'm open to why we shouldn't do it Context, but if we did it in cli then the same logic wouldn't apply to anyone using Context/Workflow as ruby classes right?

[kbrock]

Hey I'm open to why we shouldn't do it Context, but if we did it in cli then the same logic wouldn't apply to anyone using Context/Workflow as ruby classes right?

Totally.
I double talk here. I feel that workflow is the public interface, but I want people to pass in a context.

Maybe we need a public interface for creating a context, like we have Workflow#load

Ok, the only thing I care about is when you are creating a Map, do you have a context for each parallel branch? Are you able to handle this conversion?

If so, lets

[agrare]

Ok, the only thing I care about is when you are creating a Map, do you have a context for each parallel branch? Are you able to handle this conversion?

Yes, each ItemProcessor iteration has its own ItemProcessorContext which lives under the top-level Context["State"] for the Map state.

[agrare]

@Fryguy what do you think of this, something that we want to do?

[miq-bot]

Checked commit agrare@0698fcf with ruby 3.1.5, rubocop 1.56.3, haml-lint 0.51.0, and yamllint
15 files checked, 0 offenses detected
Everything looks fine. 👍

[Fryguy]

Yes I think this is something we want to do. Actually had a few questions of we can chat about it.