Closed pintsized closed 3 years ago
It's not by design per se, but originally tags were meant to apply to just regular jobs. You can apply tags to a recurring job, but that just controls how tags are applied to the jobs that are spawned from it.
I'm not sure off hand what technical issues might prevent heterogeneous get
and top
, but I'm not strictly opposed to it in principle.
Ah, I see, I hadn't clocked that spawned jobs inherited the tags. Probably leave it then - I'm just writing a binding and came across the inconsistency when writing tests, but now I know what to test for. I don't need the feature specifically, and thinking about it, it could get confusing if both the parent and child jobs showed up in a tag search.
Perhaps this is by design, but I would have thought that "get" and "top" should return a union of ql:t and ql:r when searching for tags?