Unreleased work queue item no retry on cleanup rationale?

[AndreyKudinov]

There is a change in 6.5: If a work queue item is locked at the end of a session, the clean up process now only marks the item with an exception. Previously this scenario would automatically create a retry for the queue item. I havent tested it yet(holidays), but does it mean that any unexpected process exit, like mapiex crashing automate.exe or immediate stop action would result in queue item not being marked for retry regardless whether retry limit reached or not? Maybe I misunderstood the description, but I don't see a rationale behind this change. I would expect exception to be followed with retry, just like when it is set via action. I cant think of any scenario right now where this is expected/desired behaviour.  If specific queue item should not be retried for some reason, it could be marked with exception from control room imo.

[DaveMorris]

I agree with your interpretation of the description. I also wouldn't like this change. I rely on the fact that new items are created in that situation as long as the attempts limit has not been reached. I haven't tested it either yet.

[MelissaSuarez_G]

I haven't tested either, but I imagine that they did it to prevent reworking items without investigating what caused the termination. For some automations it's ok to do so, especially if there is a retry-limit-logic in place; but if the automation involves transactions (like payments), I can see why someone would like to investigate the exception before reworking the item. I think that it would be nice if this feature were optional, like having a checkbox in the Work Queue configuration screen to activate/deactivate this option.

[John__Carter]

Thanks for mentioning this guys, I'm not at all happy with this change and have raised it with the product team.