hi there,
i have a cylc 8 workflow which is running fine but has a completed task hanging around, see screenshot.
the offending task (is ‘orphaned’ the right word?) completed fine and somehow doesn’t seem to be stopping the workflow from running but it’s puzzling to know why it’s there!
any ideas?
thanks
Interesting. Is it there in the other views too (tree and table)?
Also, if you do cylc dump -t u-cw633/run1, is it listed there?
yeah it’s there in all views, and cylc dump, strange!
> cylc dump -t u-cw633/run1
coupled, 19880601T0000Z, succeeded, not-held, not-queued, not-runahead
coupled, 19880701T0000Z, submitted, not-held, not-queued, not-runahead
coupled, 19880801T0000Z, waiting, not-held, not-queued, not-runahead
postproc, 19820501T0000Z, succeeded, not-held, not-queued, not-runahead
postproc, 19880701T0000Z, waiting, not-held, not-queued, not-runahead
Next thing, can you try stopping and restarting the workflow? (That’s safe to do, even if tasks are running at the time).
Thanks, that cylc dump output is very helpful to us in narrowing down the source of the problem. We have now seen this but at present can’t reproduce it reliably 
ok just sent the cylc stop command. it’ll take a while to finish the active tasks so i’ll let you know how it gets on hen i restart it. thanks
Note you don’t have to wait for running tasks to finish before shutdown:
$ cylc stop --now <workflow_id>
This will shut the scheduler down and leave the active tasks running. On restart, Cylc will automatically reconnect with the orphaned tasks, or update itself appropriately if they succeeded or failed during the downtime.
good to know! is this a new cylc 8 thing?
i’ve stopped and started the offending workflow now and the old task is still there, very odd!
cheers
Nope, Cylc has had that magic capability for a long time!
(Magic, because Cylc can figure out what happened to orphaned jobs during scheduler downtime even if they are long gone from the system when you start up again).
Next, try killing your UI Server (cylc gui) and start that again.
(It is probably just an object - representing the old task - in the datastore that feeds the UI, that was not cleaned up when it should have been as the workflow moved on).
If the task is visible in cylc dump, then the problem is at the cylc-flow end. You should see the same thing in cylc tui which doesn’t go through the UI Server.
We’ve recently seen a similar situation where a succeeded no-flow task in the database was causing tasks one edge out to display in the GUI. When we hacked the no-flow task away from the DB the spurious tasks disappeared on restarted.
Good point (so my UI Server restart suggestion won’t help). It is still, I think, in the datastore though, as opposed the scheduler task pool (not that that will make any sense to users).
The task wasn’t in the pool in our example either, although poking at the DB there were a few tasks there which shouldn’t have been, this appeared to just be a delayed database operation.
hi there,
i restarted the UI and that previous task has gone now but there’s a new one there now that shouldn’t be 
!
it’s also there in the cylc dump output and by the looks of it, the new task which is showing up is coming from the time when i stopped workflow toward the end of last week so maybe that helps with the diagnosis?
cheers,
> cylc dump -t u-cw633/run1
coupled, 19900401T0000Z, succeeded, not-held, not-queued, not-runahead
coupled, 19900501T0000Z, running, not-held, not-queued, not-runahead
coupled, 19900601T0000Z, waiting, not-held, not-queued, not-runahead
postproc, 19881001T0000Z, succeeded, not-held, not-queued, not-runahead
postproc, 19900501T0000Z, waiting, not-held, not-queued, not-runahead
Looks like a common theme with these tasks showing when they shouldn’t may be they were present at the point of shutdown/stall?
@MetRonnie yeah looks that way to me
