Hey everyone, I have a feature-request and thought I would post here before opening a github issue. For some context, I currently run workflows where tasks are long-running and the bottleneck is actually my Executor -- specifically, I have more tasks to run than resources available. Because of this setup, the "duration" of each flow run is very misleading. Attached is an example screenshot where all of these flow runs actually took the same time (the increase over time is because "duration" in the UI includes pending times). Would it be possible to support an alternative measure of a flow-run's duration? Currently, duration is given as when all tasks hit a pending state to when tasks all finish. It would be more useful (to me at least) to see this bar plot based on the “sum of task durations”.

Hm this is an intriguing request @Jack Sundberg - one question in my mind though is that it doesn't provide a clear way to account for tasks running in parallel; they'll always be summed in this world

Yeah that's good point and I thought about the parallel tasks as well. If we want to account for parallel tasks in the new "duration" definition, there are a number of extra scenarios that come into play -- such as whether or not the parallel tasks started at the same time and/or how much they overlap with the other tasks. If we ignore parallelization and stick to "sum of all task durations", we are getting a measure of total CPU time -- which I think is more useful than the total real time.

So the suggestion wouldn't be to replace duration but instead to provide a supplemental alternative?

Yep! In the top right of the plot, there's an option to "Normalize". It would be nice to have another option that allows you to use "total CPU time" instead of duration.

We can open a ticket for this 🙂

@Jack Sundberg I could see that being a helpful data point too, but personally would likely only use it when troubleshooting flow runs. Day to day I'd be interested in the actual wall time from pending to finished. Is that the context for you too? I could see a CSV export of flow run stats maybe being helpful here, with a row for every (task run, state) tuple. Possibly querying the flow_run/task_run tables in GraphQL api could be helpful here too?

@Andrew Hannigan I think I would always prefer CPU time because the default "duration" is very misleading in my use-case (see screenshot above). And yes, I could get this data from graphql, but it would be much more convenient to have it in the UI so I can monitor at a glance, rather than running scripts and going through tables.