Cylc-flow: Datastore misses some deltas

Created on 19 Mar 2021  路  1Comment  路  Source: cylc/cylc-flow

(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.

bug

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 === 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).

>All comments

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).

Was this page helpful?
0 / 5 - 0 ratings