Order stuck in BEING_PROCESSED state albeit haven been failed

[thraen]

It's possible that an order is stuck on a vehicle although it has been failed. The screenshot shows that robot_1 is assigned Order Move..2F, and can't start the next movement order because of it. Said order is in FAILED state as reported by the rest api:

  {
    "dispensable": false,
    "name": "Move-01JXWPA6ZF94M2Y2NTYK6SZ82F",
    "peripheralReservationToken": null,
    "wrappingSequence": null,
    "type": "-",
    "state": "FAILED",
    "intendedVehicle": "robot_1",
    "processingVehicle": "robot_1",
    "destinations": [
      {
        "locationName": "B",
        "operation": "MOVE",
        "state": "TRAVELLING",
        "properties": []
      }
    ],
    "properties": []
  },

Note that the destination state is 'TRAVELLING'.

Trying to retract this orders is refused by tcs with the remark in the log:

 o.o.s.b.dispatching.TransportOrderUtil.abortOrder()    : Transport order 'Move-01JXWPA6ZF94M2Y2NTYK6SZ82F' already in final state 'FAILED', skipping withdrawal.

[swltr]

@thraen Is there anything in the log related to that transport order before that? Can you provide the complete log, spanning the time from the transport order's creation to the message you quoted?

[thraen]

Sorry for the late reply. I'm not sure whether it makes sense to go after that..

I'm implementing a VDA client and naturally during development my client behaves often non-conformant or buggy. The issue I raised might well be something that doesn't occur with good clients.

Nevertheless, I find there should be a way to forcibly flush all tcs order states for these kind of situations.

[thraen]

Particularly, I think in this case:

o.o.s.b.dispatching.TransportOrderUtil.abortOrder()    : Transport order 'Move-01JXWPA6ZF94M2Y2NTYK6SZ82F' already in final state 'FAILED', skipping withdrawal.

there shouldn't be anything wrong with withdrawing the order, even though it's failed already.

[swltr]

In your screenshot, the order's state is BEING_PROCESSED, which is not a final state. It was probably either FINISHED or FAILED already, and the state shown in the table was outdated for some reason. That would be a bug. In case this happens again, please check both the log of the Kernel as well as that of the Operations Desk application - especially the latter.