I have about 105 stuck workflow instances due to a deserialization issue. Cannot seem to get to the bottom of this. I have restarted my docker containers (running Operate and Simple Monitor) thinking that there is probably a cached class metadata somewhere. However, Operate still shows 105 stuck instances.
How do I clear this data?
Hi @klaus.nji can you help me to understand what the problem is? Can we create a reproducer to highlight the root cause of the problem?
Can you explain how did you first notice the problem? so I can replicate it here
@salaboy, I have attached a copy of my test project at this url: https://1drv.ms/u/s!AvY3eZNsWv_Qgad7sUKaVkhbgFHK9g?e=Y3QPcY. This is a simple microservice application based on the micronaut framework which exposes an endpoint you can post a command to. Service will run on port 8085 but you can change the port in application.yml. If you submit a POST request to localhost:8085/api/orders/order with this body
{
"item" : "headphones",
"numberOfItems" : 2,
"price" : 200,
"paymentMethod" : "VISA",
"accountNumber" : 4567
}
It will trigger the workflow order-process.bpmn.
I am not able to get this workflow to run to completion 100% of the time. I will be luck to get it to run to completion 20% of the time.
How do I clear this data?
Delete the docker volumes.
Thank you.
@klaus.nji quick question… Do you understand that all the processes that go to “Cancel Order” will not finish due they haven’t hit an “End event”? Can you please add an end event and then share with us if you are still facing the same issue?
HTH
@salaboy, yes I understand that but my orders so far are not getting to the point where an order is canceled. Even if this was the case, I should see all the failed workflows terminating at the Cancel task and this is not the case. Also, this does not explain why workflows fail at the very initial step. Since I have two threads related to this issue, I suggest we continue this discussion on the other thread and deal with Operate issues on this one.
