Ending a Wait node

[azriel46d]

The documentation lists that a wait node can be terminated using

POST api/queue/update/{workflowId}/{taskRefName}/{status}

However, with the below definition of my WAIT node

{
  "name": "waitForExtCheck",
  "taskReferenceName": "waitForExtCheck",
  "inputParameters": {},
  "type": "WAIT",
  "startDelay": 0,
  "joinOn": [],
  "optional": false,
}

I am not able to trigger the POST request successfully.
for workflowId I am using the workflowInstanceId and the task reference name from the above definition is used.

The response I get however is:

{
  "status": 400,
  "message": "INVALID_INPUT - There is no queue for handling COMPLETED status",
  "retryable": false
}

Also checking the queue for the WAIT node is always set to zero.

The above also brings about another question. Most times a SIMPLE node needs to hold information about an upcoming WAIT node.
( a scenario i have for example is that a TASK X needs to do some validations, if they fail a user goes in to a separate tool , and triggers the adjustment/approval , which would be the wait hit a separate microservice API call and do some additional work and call the wait node once complete)
The way I figured was that the SDKs provide the workflowInstanceId and the I'd pass in as part of the inputs the reference name to the WAIT node. What is the best practice for this?

[dougsillars]

Hi @azriel46d ,
Great questions. Let's start from the calling of the WAIT task, and the queue. When your wait task is ready, it is put in the queue for a worker to pick it up. Once a worker grabs the WAIT, it's status is "IN_PROGRESS" and it's no longer in the queue - it is actively waiting.

Queues: it appears there are no completed queues set by default. My OSS is connected to AWS SQS where we have COMPLETED and FAILED queues - so these endpoints work for me.

If i understand - your worker does some work and it either "passes" or "fails". If it fails - more stuff (outside Conductor needs to be done... you can query api/workflow/{workflowId} and see all of the tasks inside the workflow - so you could extract outputs from other tasks (not just the WAIT) if needed.

Doug

[v1r3n]

@azriel46d The endpoint only works if you have event queues (e.g. SQS integration) configured. We plan on sending a PR that allows you to accomplish the same without needing event queues. I will update this thread once the PR is sent.

Meanwhile, you can use the following API to accomplish the same:
POST api/task/update/ with payload that contains taskId and workflowId

[NItaMII]

Hi @v1r3n Are there any documents about the event queues?

[azriel46d]

@v1r3n @dougsillars Thanks for the comments. In fact the only way I managed to get it to work was utilising POST api/task/update/.
What I was trying to avoid was that a particular task is "bound" to the wait task which is found further along in the flow. I'll try and explain how I'm thinking of going about it since the above POST request does not support the name and also to satisfy the condition that they are not tightly bound.

The way I'm seeing the solution right now is

1. As part of the inputs of the Task node, the taskReferenceName is passed.

{
      "name": "backofficeRules",
      "taskReferenceName": "backofficeRules",
      "inputParameters": {
        ....
        "onPending": "waitForPendingValidation"
      },
      "type": "SIMPLE"
}

2. The task would query the workflow instance, to get the ID of that particular task. ( The complexity will arise if the task is in a sub workflow)
3. Trigger the API call to affect the WAIT node using the retrieved IDs

Hope this clarifies it a bit more. If the POST above can be done using the taskReferenceName instead of the ID it would make step 2 redundant.

[NItaMII]

@azriel46d api support using taskReferenceName, look at 'queue/update/{workflowId}/{taskRefName}/{status}' API. Hope it will help.