`cylc dump` still showing more than just `n=0` tasks
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 # <-------
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?
I thought #7075 may have fixed this, so I checked..
However, it appears to be already working correctly on 8.6.x:
@hjoliver - Can probably close this
(likely fixed with one of my window calc/depth refactors)
Can confirm that this bug no longer reproduces!