cylc
tasks waiting on xtriggers etc. are n=1
Tasks waiting on any kind of external triggers currently appear as "waiting" in the scheduler task pool, and are consequently seen as n=0 active tasks in the data store.
However, as argued in the n-distance window proposal they should be seen as n=1, because they are one graph edge downstream of the "active" triggers that they are waiting on. This should be literally true in the future once we can spawn tasks off of trigger events, but until then the data store should artificially show these tasks as n=1, not n=0.
Note this makes a difference (to what is seen in the UI) even in n=0 and n=1 windows.
Maybe they shouldn't be released to the active pool? Because that's the trigger for n=0 task creation/assignment.
The trouble with that is, we don't (yet) have xtriggers etc. as real n=0 entities in the graph, so edge-following from n=0 will not find these tasks.
Well, they (the tasks) been spawned (I assume) into the active pool.. Remind me, where to tasks that are spawned but have unmet prerequisites sit? (which pool?) Can't quite recall
I just want to make sure we're fixing the right thing, because n=0 (or the current active tasks) is the basis for the window.. (would be extra complication to have n=1 with no n=0)
Maybe it would be best to create xtrigger nodes (in the data-store at least)
Tasks with partially satisfied prerequisites are now hidden in the runahead pool. But those are task prerequisites. We don't currently consider xtriggers, clock-triggers, etc. to be "prerequisites" even though we should.
Tasks that depend on a clock-trigger (say) are currently spawned into the active pool for pragmatic reasons:
- we don't yet have clock-triggers etc. as entities in the n=0 pool that can spawn the children downstream of them, so they get auto-spawned as if they had no prerequisites
- we want these waiting tasks to be visible in the UI, as they are "what comes next" - just like tasks waiting on other tasks
Yes this will be an extra complication; the question is where best to handle it. (If it is too complicated, we could punt this until the proper solution: xtriggers etc. in the graph and in n=0).
Maybe it would be best to create xtrigger nodes (in the data-store at least)
Possibly - that's essentially the correct solution as I've said above - but I'm not sure how difficult that will be. My feeling is, what I'm suggesting should be a relatively easy interim solution that works just as well for the tree view (the eventual graph view will need the proper solution).
We could keep these tasks hidden in the runahead pool, of course, to exclude them from n=0. But then we'd just have to interrogate the runahead pool instead of the main pool, to put them in n=1 (because they can't be found by edge-following from n=0 ... until we have xtriggers etc. in n=0).
For the datastore to find n=1, could we not just do this:
- edge-follow from n=0 (as now, but excluding these tasks as discussed)
- and find these tasks (in the main pool, or runahead pool, or wherever)
- (then for n=2 etc. carry on as usual: only edge following)
For the datastore to find n=1, could we not just do this:
- edge-follow from n=0 (as now, but excluding these tasks as discussed)
- and find these tasks (in the main pool, or runahead pool, or wherever)
- (then for n=2 etc. carry on as usual: only edge following)
Come to think of it, we can just start the window on that node as n=1... But I may have to take a look at it (as there will be rules around pruning etc for n=0)..
Perhaps they are best to be node like.. The exception to the rule would be suite_state xtrigger; where you actually want it to be a ID reference to a node in a different suite.