Open claymcleod opened 2 months ago
What's the use case exactly? Would you imagine this as an admin endpoint (total counts for tasks submitted by all users) or a user-specific one (total counts for tasks submitted by a given user)? If the former is fine for your use case and we don't consider these counts sensitive, we could add it to the service info in the same way WES does:
system_state_counts:
type: object
additionalProperties:
type: integer
format: int64
Not sure what happened to the description. Seems they got inadvertently lost between 1.0.0 and 1.0.1. Anyway, it used to be:
The system statistics, key is the statistic, value is the count of runs in that state. See the State enum for the possible keys.
Oh, that's a good question. Most of my thoughts (including this one) are going to be from a user's perspective. Here, the goal would essentially be to facilitate a dashboard of "my" jobs in a particular TES server that I run locally.
We prototyped something like this in our biohackathon here: https://github.com/stjude-biohackathon/KIDS24-team15/tree/main/tes-dashboard.
Fair enough. Probably something to discuss with WES. Any other dashboarding/stats features you can think of? Could perhaps be addressed/discussed together.
I'd consider adding a summary endpoint that summarizes the state of all of the tasks submitted to the server—this way, if you just want to get the counts in each state, you don't have to iterate over the entire collection of tasks (saving server bandwidth and time overall).