cylc-flow icon indicating copy to clipboard operation
cylc-flow copied to clipboard

`cylc dump` still showing more than just `n=0` tasks

Open hjoliver opened this issue 1 year ago • 1 comments

Test case:

[scheduling]
    [[graph]]
        R1 = "foo => bar"
[runtime]
    [[foo]]
        script = false
    [[bar]]

When this stalls with 1/foo failed, manually trigger 1/bar - which will succeed and leave the task pool.

After this, cylc dump shows 1/bar as present in n=0 even though it is not there (it will be at n=1 relative to the incomplete failed 1/foo):

$ cylc dump -t --flows bug          
bar, 1, succeeded, not-held, not-queued, not-runahead, [1]  # <------ 
foo, 1, failed, not-held, not-queued, not-runahead, [1]

I can confirm that 1/bar is not actually in the pool by trying to remove it:

INFO - Command "remove_tasks" received. ID=49c118ba-2252-4eaa-b4d0-326916a39e57
    remove_tasks(tasks=['1/bar'])
WARNING - No active tasks matching: 1/bar  # <-------

hjoliver avatar Sep 11 '24 06:09 hjoliver

Reproduced. The cylc dump command is querying tasks using the graphDepth argument to filter by n-window.

The graphDepth in the data store is incorrect. This query:

{
  workflows {
    taskProxies {
      id
      graphDepth
    }
  }
}

Returns:

{
  "data": {
    "workflows": [
      {
        "taskProxies": []
      },
      {
        "taskProxies": [
          {
            "id": "~me/tmp.yHSiyZYCNF/run1//1/foo",
            "graphDepth": 0
          },
          {
            "id": "~me/tmp.yHSiyZYCNF/run1//1/bar",
            "graphDepth": 0
          }
        ]
      }
    ]
  }
}

If I reload the workflow, then the graphDepth is correctly changed to 1.

          {
            "id": "~me/tmp.yHSiyZYCNF/run1//1/bar",
            "graphDepth": 1
          }

So this is likely a missing data-store call? Or the data is going in, but the update isn't going out?

oliver-sanders avatar Sep 11 '24 15:09 oliver-sanders

I thought #7075 may have fixed this, so I checked..

However, it appears to be already working correctly on 8.6.x:

Image Image

@hjoliver - Can probably close this

(likely fixed with one of my window calc/depth refactors)

dwsutherland avatar Nov 20 '25 02:11 dwsutherland

Can confirm that this bug no longer reproduces!

oliver-sanders avatar Nov 20 '25 17:11 oliver-sanders