-
Notifications
You must be signed in to change notification settings - Fork 1.1k
[24.2] Ensure job states are fetched in invocation view #20010
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[24.2] Ensure job states are fetched in invocation view #20010
Conversation
Fixes galaxyproject#20003 We weren't checking if the job states summary had been fetched before we had the ``` if (invocationSchedulingTerminal.value && jobCount.value === 0) ``` check. `jobCount` would always be 0 if the states summary hadn't been fetched yet.
**For a singular invocation** (excluding cases of batch runs), we now push to the `workflows/invocations/{invocation_id}` route when the workflow is run.
Without this, we would stay on the `workflows/run` route and refreshing would take you back to the run form, instead of the invocation view.
client/src/components/WorkflowInvocationState/WorkflowInvocationState.vue
Show resolved
Hide resolved
client/src/components/WorkflowInvocationState/WorkflowInvocationState.vue
Show resolved
Hide resolved
As we can see this value being set in `summarize_invocation_jobs` here https://github.com/galaxyproject/galaxy/blob/4a0cca07d97d7bbd22eb39ddab38d4d4354aa4fa/lib/galaxy/managers/jobs.py#L957-L1000, `new` seems to be a non-terminal `populated_state`, meaning this summary will have updates which will eventually produce some state counts. To fix the bug of never getting a state count for the invocation view before the scheduling state becomes terminal, we now wait for the state to be something else than `new`, and only then look for other reasons to stop polling.
mvdbeek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks good to me, thanks @ahmedhamidawan!
|
But the selenium tests look related ... |
This means that we show the little icon to switch to the history for the invocation if that history isn't current, regardless of if results were generated in a new history or not.
|
This was happening because we now push to invocation route on workflow run, and hence, we were unable to pass the |
|
Excellent, that was another minor thing I didn't like, a 2 for 1! |
|
Thank you! |
Fixes #20003
We weren't checking if the job states summary had been fetched before we had the following check:
jobCountis always 0 if the states summary hasn't been fetched yet or hasstates: {}; which can happen when thepopulated_state === "new". Now we check for that and keep polling until we see some other state thannew.(Additional Improvement) Route to Invocation on Run
For a singular invocation (excluding cases of batch runs), we now push to the
workflows/invocations/{invocation_id}route when the workflow is run.Without this, we would stay on the
workflows/runroute and refreshing would take you back to the run form, instead of the invocation view.TODODone ✅:(If problematic (for merge forwards) I can target dev in another PR just for tests? Doesn't seem bad though...)
How to test the changes?
(Select all options that apply)
License