You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many workflow engines can validate that a workflow is syntactically correct and inputs/ input files are correct. Making this capability available via an API call would be very valuable.
The response could be 200 OK with a body including a list of errors, or an empty list if there are no errors. Alternatively a 203 No Content response might be used to indicate no error?
More capable engines may even be able to perform a dry run as part of the checks.
The text was updated successfully, but these errors were encountered:
I like the idea, but I would expect that this is still quite a long/blocking operation, at least for some engines, and so it might need to be handled asynchronously. In that case, a 200 or 203 response would not be sufficient, but rather this would need to be implemented similar to a regular run, an identifier would need to be returned, a status attached etc.
An alternative then to adding one (or possibly more!) endpoints for validation/dry runs, would be just passing the appropriate parameters to workflow-engine-parameters, like, e.g., in Nextflow and Snakemke with -stub-run and --dry-run, respectively. And the ability to return multiple error responses (great idea!) might potentially be implemented through modifications of the ErrorResponse schema.
Many workflow engines can validate that a workflow is syntactically correct and inputs/ input files are correct. Making this capability available via an API call would be very valuable.
The response could be
200 OK
with a body including a list of errors, or an empty list if there are no errors. Alternatively a203 No Content
response might be used to indicate no error?More capable engines may even be able to perform a dry run as part of the checks.
The text was updated successfully, but these errors were encountered: