set default log file by job outcome #2025
Conversation
markgrahamdawson
force-pushed
the
1241-log-view-set-default-log-file-by-job-outcome
branch
from
dfe8147 to
8f97803
Compare
fix re-implemented based on review fix broken E2E test fix tests review ammends added change log
markgrahamdawson
force-pushed
the
1241-log-view-set-default-log-file-by-job-outcome
branch
from
f31427b to
44e4d78
Compare
| let result | ||
| try { | ||
| // get the list of available log files | ||
| result = await this.$workflowService.apolloClient.query({ |
There was a problem hiding this comment.
We've got an interface for performing queries like this. It's got a silly name and isn't documented or explained (sorry). The workflow service code is in need of refactor but rather low priority.
I think this should work with no other changes, but give it a try first:
| result = await this.$workflowService.apolloClient.query({ | |
| result = await this.$workflowService.query2({ |
| query JobState($id: [ID!]) { | ||
| jobs (live: false, workflows: $id) { | ||
| id | ||
| state | ||
| } | ||
| } |
There was a problem hiding this comment.
This isn't requesting the state of a single job, it's requesting the state of all jobs in the entire workflow. This is why you have to filter for the specific job ID in the code later on.
Workflows can accumulate many hundreds of thousands of jobs over their lifetime so this could become a bit of a problem.
There is an ids argument which is supposed to filter this down as well as a tasks argument (which I don't think makes sense in this context). I tried these out in graphql and to my horror found that neither actually do the job 🤦. Dammit!
E.G, here I am filtering by workflow, task and job ID, but I still get two results from two different cycles:
query JobState($workflow_id: [ID!], $task_id: [ID!], $job_id: [ID!]) {
jobs (live: false, workflows: $workflow_id, tasks: $task_id, ids:$job_id) {
id
state
}
}{"workflow_id":"generic/run5//20191209T1200Z/foo/", "task_id":"foo", "job_id":"20191209T1200Z/foo/run1"}{
"data": {
"jobs": [
{
"id": "generic/run5//20191209T1200Z/foo/01",
"state": "0"
},
{
"id": "generic/run5//20191210T0000Z/foo/01",
"state": "0"
}
]
}
}This is going to need a bit of work on the backend to resolve.
I think this PR should be using the ids field.
There was a problem hiding this comment.
Here's the source of the problem:
It only makes use of the task argument (which does work but can return the same task from multiple cycles and multiple job submissions for the same cycle) and completely ignores the id argument (because this hasn't been implemented yet).
| console.warn(err) | ||
| return | ||
| } | ||
| const job = result.data.jobs.find(x => x.id === this.id) |
There was a problem hiding this comment.
We shouldn't have to filter for the job by its ID because there should only be one job returned by the query.
This made me take a look at the query and realise that we're getting all jobs back in the response, dammit.
This pr now implements setting default log file by job outcome in two ways:
If the user navigates to the log view through the node menu the job state is passed to the view as in this pr...
master...MetRonnie:cylc-ui:menu-log-file
If the user manually types in the path of the job via the input in the log view a new query is made as in this pr...
offline data: enable querying failed jobs cylc-uiserver#657
Closes #1241
Check List
CONTRIBUTING.mdand added my name as a Code Contributor.setup.cfg(andconda-environment.ymlif present).?.?.xbranch.