I am using the workqueues for standard enqueue/dequeue processing. The enqueue Flow adds a row to the correct workqueue, and the dequeue Flow runs when a row is added to the correct workqueue. I am seeing two random issues on the dequeue side, <5x/week:
1) Shortly after the dataverse "when an item is added" runs (after variable initiations and an HTTP call) I run a delete row on the workitemid returned from the trigger. However, even though the id is identical, it sometimes fails with not found.

2) Sometime the enqueue function creates the queue item with different queue and internal row id values, but the same workitemid values. When the second one runs with the same id, the Flow runs as it's found from "when an item is added", but the delete fails as well and items remain on the queue. Note this is unrelated to the above problem - in this case the reason it won't delete is that it thinks it's already been deleted. I tried using those other two values in the Dataverse operations, but they fail. Example:
Input: 364623
Workitemid: 6787cd42-ba63-ef11-bfe2-002248248f2b
Queueitemid: system-c5bdbb5d-e2d3-4333-a971-12416e5d3804
Timestamp: 2024-08-26T14:48:36Z
Row unique id: 27924877-e7d0-4ea4-9a03-7c077729aabc
Input: 364620
Workitemid: 6387cd42-ba63-ef11-bfe2-002248248f2b
Queueitemid: system-d601689a-d1ba-4cac-a8af-72567d61650f
Timestamp: 2024-08-26T14:48:34Z
Row unique id: adaa5f7f-e08b-4311-9b81-c5ef53cf6854
I assume 1) is due to some kind of locking where it just needs more time run the delete, and moving the delete farther down in the Flow should help (problem happens rarely it's difficult to know if it's fixed) but would like to confirm. As an example, in the failure case the time difference between trigger and delete was 1s, and for the passing ones it was 2s or more - pushing it down is now >4s. It doesn't seem to retry. For 2) there is a workitemid field when adding a row but if you try to populate it fails.
Both seem like bugs but can be worked-around by adding "configure run after" if the delete fails. Is there a reason these can happen, or are they bugs? Should update be used instead of delete, and then delete at the queue level ("items expire after" setting, since it either processes after 5 mins or will never process)?
Thanks,
John