Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@ahmedhamidawan
Copy link
Member

@ahmedhamidawan ahmedhamidawan commented Apr 14, 2025

Fixes #20003

We weren't checking if the job states summary had been fetched before we had the following check:

if (invocationSchedulingTerminal.value && jobCount.value === 0)

jobCount is always 0 if the states summary hasn't been fetched yet or has states: {}; which can happen when the populated_state === "new". Now we check for that and keep polling until we see some other state than new.

(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/run route and refreshing would take you back to the run form, instead of the invocation view.

TODO Done ✅:

  • Add tests
    (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)

  • I've included appropriate automated tests.
  • This is a refactoring of components with existing test coverage.
  • Instructions for manual testing are as follows:
    1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

  • I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

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.
@ahmedhamidawan ahmedhamidawan marked this pull request as draft April 14, 2025 23:57
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.
@ahmedhamidawan ahmedhamidawan marked this pull request as ready for review April 15, 2025 00:35
Copy link
Member

@mvdbeek mvdbeek left a 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!

@mvdbeek
Copy link
Member

mvdbeek commented Apr 15, 2025

But the selenium tests look related ...

@mvdbeek
Copy link
Member

mvdbeek commented Apr 15, 2025

From the failing test:
last

I think there's a badge ("new history badge") missing here that let's you switch to the new history ?

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.
@ahmedhamidawan
Copy link
Member Author

This was happening because we now push to invocation route on workflow run, and hence, we were unable to pass the newHistoryTarget prop and show the badge.
Removed that prop and now we show the badge 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.

@mvdbeek
Copy link
Member

mvdbeek commented Apr 15, 2025

Excellent, that was another minor thing I didn't like, a 2 for 1!

@mvdbeek mvdbeek merged commit 0579f32 into galaxyproject:release_24.2 Apr 15, 2025
26 of 27 checks passed
@mvdbeek
Copy link
Member

mvdbeek commented Apr 15, 2025

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants