For the email variable, we might want to require that it follows the "email" regex.
For the customer-id variable, we might want to require that the customer-id references a valid record in our customer database (external to LittleHorse).
There are additional types of validations that we might want to do, such as ensuring that a certain combination of variables is unique (i.e. a userId needs to be unique within an organization but not globally unique, so we can't use it as a WfRunId to enforce uniqueness).
Currently, the only way to enforce those validations is to do it before making the call to RunWf. I believe that we can improve this. Some ideas are as follows:
For the first item, which is a simple email validation:
Introduce the concept of a schema that sits alongside the VariableType enum inside the VariableDef structure.
Enforce schema compatibility in the RunWfRequestModel#process() method.
The second type, where we need to check with external systems, is slightly more complex. However I think we could introduce a new workflow concept like a ValidationTaskRun which is part of the ENTRYPOINT Node. It would work as follows:
User specifies a ValidationTaskDefName which is part of the ENTRYPOINT Node.
When the WfRun is created, a TaskRun is scheduled on the appropriate TaskDef.
The RunWfRequest does not return to the user until that TaskRun is completed.
If the TaskRun throws an error, the WfRun moves to ERROR and does not advance past the ENTRYPOINT Node. The error is returned to the client.
If the TaskRun completes successfully, the WfRun advances past the ENTRYPOINT Node and the WfRun is returned to the client.
However, this introduces some additional complexities around timeouts, etc.
Oftentimes, we have variables in a
WfSpec
as follows:We might want to enforce two validations:
email
variable, we might want to require that it follows the "email" regex.customer-id
variable, we might want to require that thecustomer-id
references a valid record in our customer database (external to LittleHorse).There are additional types of validations that we might want to do, such as ensuring that a certain combination of variables is unique (i.e. a
userId
needs to be unique within anorganization
but not globally unique, so we can't use it as aWfRunId
to enforce uniqueness).Currently, the only way to enforce those validations is to do it before making the call to
RunWf
. I believe that we can improve this. Some ideas are as follows:For the first item, which is a simple email validation:
schema
that sits alongside theVariableType
enum inside theVariableDef
structure.RunWfRequestModel#process()
method.The second type, where we need to check with external systems, is slightly more complex. However I think we could introduce a new workflow concept like a
ValidationTaskRun
which is part of theENTRYPOINT
Node. It would work as follows:ValidationTaskDefName
which is part of theENTRYPOINT
Node.WfRun
is created, aTaskRun
is scheduled on the appropriateTaskDef
.RunWfRequest
does not return to the user until thatTaskRun
is completed.TaskRun
throws an error, theWfRun
moves toERROR
and does not advance past theENTRYPOINT
Node. The error is returned to the client.TaskRun
completes successfully, theWfRun
advances past theENTRYPOINT
Node and theWfRun
is returned to the client.However, this introduces some additional complexities around timeouts, etc.