"Pending" state on WO doesn't appear until retries are claimed

[taylordowns2000]

"Pending" state on WO doesn't appear until retries are claimed. (It should appear when they are enqueued.)

• To reproduce, turn off your worker and reprocessing a workorder.
• A new attempt will be enqueued, but the associated workorder will never have their state set to pending
• I think it's important for the end user to know that a workorder has an attempt enqueued

[taylordowns2000]

@NickOpenFn , what do you think about this one?

[midigofrank]

@taylordowns2000 workorders don't have the available state. They go from pending --> running. As for attempts. the enqueued status gets displayed as seen in the screenshot. You need to filter for pending and running workorders to see this because it happens so fast

screenshot

[taylordowns2000]

That's not quite the issue here @midigofrank . Head to demo.openfn.org and rerun the last ten successful workorders and you'll see what i'm talking about.

it's nice that they go to pending when they're claimed, but i mean that we should update the workorder state to show that attempts and enqueued. we don't do this. the change would be here:

in essence, i'm talking about adding Workorders.update_state(attempt) here: https://github.com/OpenFn/Lightning/blob/main/lib/lightning/work_orders.ex#L252

i don't know if that's actually the most elegant way to solve this, but i hope it makes the problem clear. when looking at workorders, there's currently no way to tell if they have attempts enqueue without unfolding them. i think that's misleading.

[midigofrank]

@taylordowns2000 just to ensure I get this right, this is an issue with workorders that have been retried. And the problem is that their status is updated from the previous one to running only after there has been an update on the attempt. Is this correct?

[taylordowns2000]

yeah that's right @midigofrank ! i will update the issue title and description now. the easiest way to see this is to start your server with RTM=false iex -S mix phx.server and see what happens when you rerun a workorder. (see reproduction steps in the original issue please!)

If you've got your worker turned off, you'll see it very clearly. This workorder is in a "success" state, when it should actually be in a "pending" state. The first attempt was successful, but the most recent attempt is merely enqueued, waiting for a worker to grab it. The code in my comment above will close this issue if you implement it, but I'm wondering if there's a better way to do it.

[midigofrank]

Okay, got it