fix(ui): stabilize workflow node execution state updates

[JPPhoto]

Summary

Fixes workflow node execution state updates in the frontend event layer.

This change fixes nodes getting stuck in IN_PROGRESS or showing duplicate outputs when socket events arrive out of order or are repeated. The fix moves the event-ordering logic into shared helpers and uses a listener-local completed-invocation key set so late invocation_started / invocation_progress events cannot overwrite a completed node state.

Related Issues / Discussions

QA Instructions

1. On main, run a workflow in the Workflow Editor and examine the Outputs pane for a node that executes. You should see two outputs even when the node is executed once.
2. After pulling and building (or running in dev mode), open the Workflow Editor and run a workflow with visible node progress.
   • Confirm nodes transition from pending to in progress to completed.
   • Confirm completed nodes do not revert back to in progress during or after the run.
   • Confirm the Outputs pane does not show duplicate outputs for a single node execution.
3. Execute pnpm vitest run to run regression tests.

Merge Plan

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• ❗Changes to a redux slice have a corresponding migration
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

[lstein]

It's a funny coincidence that I noticed the doubled output just a few days ago on my own, and was puzzled by it, not knowing whether it was a feature or a bug.

In any case, I'm having difficulty testing this PR. I set up the very simple integer operation workflow shown below. When I run it, the nodes go into permanent pending state and continue showing pending even after cancelling. On the other hand, when using an image generation workflow that previously doubled the output, the doubled output is gone. However, the nodes at the very beginning and end of the workflow get stuck in PENDING. Is there something I'm doing wrong?

(Yes, I rebuilt the front end)

[JPPhoto]

It's a funny coincidence that I noticed the doubled output just a few days ago on my own, and was puzzled by it, not knowing whether it was a feature or a bug.

In any case, I'm having difficulty testing this PR. I set up the very simple integer operation workflow shown below. When I run it, the nodes go into permanent pending state and continue showing pending even after cancelling. On the other hand, when using an image generation workflow that previously doubled the output, the doubled output is gone. However, the nodes at the very beginning and end of the workflow get stuck in PENDING. Is there something I'm doing wrong?

(Yes, I rebuilt the front end)

I think there are multiple issues here and this PR addresses double results while #9043 addresses status issues. Can you locally merge #9043 into your checkout and see if everything is better with both applied?

[lstein]

It's a funny coincidence that I noticed the doubled output just a few days ago on my own, and was puzzled by it, not knowing whether it was a feature or a bug.
In any case, I'm having difficulty testing this PR. I set up the very simple integer operation workflow shown below. When I run it, the nodes go into permanent pending state and continue showing pending even after cancelling. On the other hand, when using an image generation workflow that previously doubled the output, the doubled output is gone. However, the nodes at the very beginning and end of the workflow get stuck in PENDING. Is there something I'm doing wrong?
(Yes, I rebuilt the front end)

I think there are multiple issues here and this PR addresses double results while #9043 addresses status issues. Can you locally merge #9043 into your checkout and see if everything is better with both applied?

Will do. I'm traveling for a bunch of business meetings this week so it may be a couple days before I get back to this, but I'm anxious to get it pushed through.

[lstein]

I've created a branch that contains both #9029 and #9043 . However the problem of stuck workflows persists.

When I create the simplest workflow of them all, a single Add Integers node, and press the invoke button, about 90% of the time it gets stuck in pending state. If I create a slightly more complex workflow, such as feeding the Add Integers output into Integer Range of Size, the workflow completes about 80% of the time and get stuck in PENDING the rest of the time.

This suggests to me that there is still a race condition of some sort. Let me know if testing this the wrong way.

[lstein]

Oh, wait, I merged #9042, not #9043. Trying that as well.

No, the problem persists. This is with all three PRs (#9029, #9042 and #9043) merged into a local branch. Also I note that the single node Add Integer workflow sometimes appears to run to complete, but produces no output.

[JPPhoto]

I think I have the issue isolated. The node's initial execution state has not been put into $nodeExecutionStates before the first socket event for that node arrives. For very fast workflows, invocation_started, invocation_progress, or even invocation_complete can win that race, and the handler was previously dropping the event because there was no existing execution-state entry to update. Try this PR again now and see if that resolves the problem.