Do not update if there is a save pending

[mwdchang]

Summary

This attempts to solve another round synchronization issue - the suspected culprits are the debouncers we are using for both saving-to-db and update-from-db going out of sync with each other. The primary reason for debouncers here is because we cannot send in a stream of updates across REST API without jamming-up every one else, so to resolve around that we introduce a couple of heuristics below.

To illustrate the potential sync problem:

• Action 1: if we move operator-A, then
• Action 2: link operator-A to operator-B
• Action 1 is send to DB, and Action 2 is queued
  • As Action 2 is queued up, the response from Action 1 comes back and partially overwrite what we would've written with Action 2, at this point Action 2 is flushed tot he DB.

Heuristic 1: Do not update if there is a save action pending

Heuristic 2: Do not update if we are dragging

In both cases, we acknowledge there is an update by incrementing the version number, but skip over the fields. The idea is that, for

• heuristic 1: there is a save in progress that will result in a update-from-db, we will use that one
• heuristic 2: drag-end results in a save, which is heuristic 1

The assumption is that only a single user works on an operator at a time.

Relates to

• [BUG]: workflow nodes get misconnected for no obvious reason #4828
• [BUG]: Workflow node input ports persist after connections are unlinked #4406

Testing

This should remedy strange jerkiness/flickers, as well as weird connection states between operator ports.

[Tom-Szendrey]

Awesome!