the new public api for executions is not up-to-date to the openapispec. (url/api/v1/docs/).
lastId is missing in query
why has the getExecutions() method a query with workflowId. Call /execution/123123 if you want that execution. If it’s for searching an execution in a list, it may be better if this is a fulltext search ( id LIKE “%123%”) and not this → …(workflowId && { workflowIds: [workflowId] }) )
Some workflows are excluded via excludedExecutionsIds() with getActiveExecutions(). Why? We need all executions, even the working ones.
Why is there a hard limit of query limit 250. If I set a high limit, I know it may have performance issues.
IExecutionResponseApi says, the api should return workflowData. But this is still missing. We need the workflow name
How to get the parent executionId of a subworkflow execution (there is not any relation yet). We want to build a tree-structure monitoring, because if a sub sub sub workflow crashes, there is chaos. I guess this will be another feature request ( Link Sub Workflow with Parent Workflow )
This is used internally for pagination only. It’s serialized in the nextPage property. Meaning you cannot set the parameter hence why it’s not shown in the docs.
It’s for searching executions from specific workflows – The workflows the user who is making the API call, owns. By default, all workflows the user owns unless a workflow id is specified.
As you mentioned, to try to avoid performance issues, especially this endpoint that when used with includeData can return a huge output.
What the endpoint responds you can see in the docs. Not sure why you are trying to get this information from an interface. I see, however, how exposing some details about the workflow, such as the name, might be helpful. Perhaps, we can have a parameter called includeWorkflowData, and when set to true it also includes all the workflows.
As you mentioned, we do not have that relationship in the executions table yet.
Thanks for your feedback. Keep in mind this is our iteration of the API. I will make sure to bring your feedback up when we do the next iteration.
I look forward for the includeWorkflowData flag Nice.
So, the correct way to implement an own implementation is working with limit and nextCursor?
Are you planing to build a result filter if you want to seach for workflowName, mode, retryOf, or any field possible?
It’s ok. Mainly, we can implement a pagination and we can filter stuff (mode and parentWorkflowId [other issue] will be important for us in the future)
Nothing is planned yet, but when we gather all the feedback and meet internally to decide what goes into the second iteration this will be discussed.
Again, thanks for your feedback. If there is anything else that you found it’s not working as expected or might be nice to have, make sure to let us know.
BTW I would update the name of the feature request to “add more filters to GE /executions endpoint”.
( Link Sub Workflow with Parent Workflow )
Nice.