Task Delegation Fails with 500 Error (Works in Swagger)

0

Hi Marcin, by any chance are there any other actions that happen in the same automation, and modify the same document ?
If so have you tried moving that REST action to the first place?

We've faced similar issues and order od operations seems to be important.

I'm thinking that internally when there is an action involving SQL on the same item(I'd) it starts a transaction and locks that row for modifications untill end of the automation.

So when a REST action tries to update that document there is a lock on db level which results in timeout, as that rest action would try to execute as new transaction, not the same one. Webcon sees it as two different actions, one is executed by automation, second is not correlated it's just started as separate bg task from API endpoint.

Hi Maksymilian,
Yes, there are other actions, I've tried moving REST action to every possible place and result was still the same. Last log that I've attached is from a run where REST action was first to execute.
Even if i disable every other actions on that automation, I still get 500.

Could you share some screenshots of the automation that is running this REST action?

Hi Maksymilian,
Please find the screenshots attached.

Okay, so everything is clear now,

When there is a path started, Webcon locks that specific document, so it can't be modified by other processes (which a REST call would be treated as) until path transaction ends.
This example just won't work, as you are trying update document, while it's already being processed (Dane żądania, URL, ID Elementu).

It's not possible and in this case it is a feature not a bug.

Is there any specific reason why you are trying to delegate task instead of just creating new one with Create Task Action*?
This would provide mostly same experience, although it won't be marked.

*https://docs.webcon.com/docs/2025R2/Studio/Action/TaskAssign/Action_TaskCreation

If for some reason delegation is necessary, then a dirty workaround could be some cyclic action (let's say every 15min, from 6 to 18), which would get all documents which should be processed with task delegation, and then using for-each operator to trigger REST requests.
This won't be done in context of the document so should work, as the document won't be involved in any processing (unless it will be, then rest admin mode, and forcecheckout parameters could come in handy).

Well, I've tried "Create a task" action before, but while executing, I ended up getting error "Action "Create a Task (1229)" is not supported in current execution context". Delegation is not necessary, I thought it will be a good idea to assign a person to a task, without having to use paths.

Checked documentation*, and 'Assign Task' is not marked as viable option for 'Menu button' unfortunately.
The error it self could be a bit more clear though.

https://docs.webcon.com/docs/2025R2/Studio/Action/

bump, anyone got any idea on how to fix it?

Hi,

this is really an interesting behavior.

While it is possible the below case is possible , this is not possible for the current workflow instance.
- Checkout workflow instance 1 / open in edit mode
- Execute REST action from workflow 2 to delegate a task of workflow 1
- Edit and save workflow 1
- Changes and delegated task is shown after saving workflow 1

I have to admit that I didn't come up with delegating task via the API. This is a lot easier than creating a path on each step to update the tasks. At least if the original task owner should still be assigned.. If this shouldn't be the case, then there's no way around than using paths.

While this is an interesting finding it doesn't help much.

If you want to stick to the delegation option, then I see only one reliable solution. Start a "technical delegation workflow", populate and item list with all the workflow instances which should be updated:
- Instance id
- Assigned to user
- Delegate to user
Add a timer to the step in which the workflow has been saved and this will then execute the delegation with a short delay. This would allow that the button execution is finished before the delegation has been executed. Even if the delegation would fail, the users could continue to work and you could create a task/mail to look at this technical workflow.

The only other alternative would be a path. If you don't want to show it as a path but as a button. You could hide the path with a form rule and add a hyperlink action to the button with:
javascript:MoveToNextStep({PH:355})


Best regards,
Daniel

I just came back here to say, that this javascript:MoveToNextStep({PH:355}) in hyperlink action is genius, never thought about that one, don't have a use case, but whoa!