(After discussions on Element with @kinow and @dwsutherland)
The datastore delta methods include a check like this (e.g. for changes to the task instance is_queued flag):
def delta_task_queued(self, itask):
"""Create delta for change in task proxy queued state.
"""
tp_id, tproxy = self.store_node_fetcher(itask.tdef.name, itask.point)
if not tproxy:
return
if itask.state.is_queued is not tproxy.is_queued: # <--------------------------------------
# create a new delta...
This sometimes results in a delta being omitted when it should be created (if the delta_task... method is called more than once in a main loop iteration?). Result (e.g.) we see some is_queued flags still attached to tasks that are running or finished, in the UIs.
Hacking the above line to use if True: seems to fix the problem.
Also: the check above is probably unnecessary, because we only call delta_task_queued() (for e.g.) when we know that the queued state has changed, so by definition a delta should be created. Then, if delta_task_blah() gets called multiple times before the deltas get applied only the last one will take effect, but that doesn't really matter - the intermediate changes are essentially just too quick for the UI to see.
Depending on implementation, the fix could result in occasional no-op deltas (i.e. cylc-ui gets a delta that says to "change" a quantity to the state that it already is in) but that doesn't really matter, it should be an infrequent event and of little consequence.
The no-op change shouldn't trigger a UI change to Vue I think. Although we can control that too (in a watcher we can compare the oldVal === newVal and discard it. While there could be some JS code reacting to that change, we can make sure that that does not trigger a DOM change (which is expensive; running JS code in the browser for simple things like comparison of values is normally very fast).
Most helpful comment
The no-op change shouldn't trigger a UI change to Vue I think. Although we can control that too (in a watcher we can compare the
oldVal === newValand discard it. While there could be some JS code reacting to that change, we can make sure that that does not trigger a DOM change (which is expensive; running JS code in the browser for simple things like comparison of values is normally very fast).