Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
Because the UI sometimes makes several asynchronous requests simultaneously, when it receives a revision back from the server, it does not blindly accept it. Instead, it holds onto the Revision with the greatest version number. This works well in most cases. However, there is an edge case where it causes problems:
In a cluster with at least 2 nodes, disconnect one of them.
Go to the disconnected node and move some processors around. Don't make any other modifications, as doing so may prevent the node from rejoining the cluster.
In another browser tab go back to the cluster and request that the node rejoin.
Once the node has rejoined, the browser tab that is already open to the (previously) disconnected node does not get the new revisions. Because some modifications were made while it was disconnected, it may now locally have revision 10, for instance, while the cluster thinks the revision is 2. As a result, this browser tab shows the components in their old locations with the wrong Revision. Any attempt to modify one of those components now will fail, because the Revision is incorrect.
Given the scenario laid out here, it may seem a bit contrived. This is because it's a fairly contrived example to recreate the scenario. However, the same thing can happen when a new node joins a cluster that is behind a firewall, such as in a Kubernetes environment. The revisions that previously were loaded in the UI may no longer be the correct revisions.