specification
specification copied to clipboard
serverlessworkflow
Support for output data schema
What would you like to be added:
Currently when defining a new workflow one can specify dataInputSchema which we can use to validate the input. Yet a user starting a workflow instance does not know what the output of this workflow is. What is the expected to get when the workflow finishes? This is primarily useful for HTTP requests.
I propose in the same we have dataInputSchema to have a dataOutputSchema which accepts a JSON schema.
Why is this needed: This will make it easier to document the outputs of workflow for example in an OpenAPI document as the response from the workflow runtime. This makes it especially useful in a microservice architecture where someone can look at the OpenAPI and know what to expect.
I'm not sure how this fits in with output CloudEvents? Ideally, this output doesn't have to be a CloudEvent.
@EnriqueL8 This is a good suggestion IMO. However, we should decide if that's for informational purpose only or not. As a matter of fact, such a schema could be used to verify that the output of a workflow instance matches what's expected, just before a successfull completion. Thus, an instance that did not produce error but which's output did not match the schema could be considered as failed. This behavior could even be controlled by some flag.
Good point, I hadn't thought of it as a validation step but now that you say it it does feel natural for it to be.
I vote for same functionality than dataInputSchema, thats it, by default the output is validated againts the output shema if present. If not valid, an error is thrown.
Yet a user starting a workflow instance does not know what the output of this workflow is. What is the expected to get when the workflow finishes?
A JSON result (state data output of last workflow state) or a failure (thats dependent on the runtime).
This is primarily useful for HTTP requests.
If you are exposing workflows from rest endpoint, think you could describe your workflow using OpenAPI which does include response schema. Similarly for event-triggered workflow you can use AsyncApi.
Trying to figure out what's the purpose of this request as if we add this it can go pretty deep into what all can be added that other frameworks have already.
One thing I would like not to have to run into is users having to remove generated workflow state data just to conform to some shema. For example Foreach State outputCollection (and even inputCollection) can be created from workflow data input with jq expressions during workflow execution, and they might not conform to some output schema, and rather not force users having to code complex filter expressions to remove these things in the end ..for it just to fail when they have to do small changes/update to their workflow def.
@tsurdilo I agree with your concerns, but for these use cases, you just avoid specifying an output schema (or include it for documentation purposes and set validateOnError to false). I mean, the same than inputSchema, the new field will be optional and do not necessarily validate.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I'm gonna have a spec binge next week. Should I work on that PR too guys? @tsurdilo @ricardozanini @fjtirado
I'm a big fan of the idea, personally speaking!
@cdavernas I would like to work on it. I need to increase my contributions to the spec and this one is pretty straightforward.
PR opened https://github.com/serverlessworkflow/specification/pull/696. I reuse the text for dataInputSchema
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.