The galaxy-tool-shed-schema package is basically pydantic models for the whole tool shed API. It is used by both the backend code for the new tool shed and the testing code that runs on both the old and new tool shed.
The creation of galaxy-tool-util-models package is something I've wanted to do for a while - it should solve some TODOs I've left in the base. I think beyond enabling galaxy-tool-shed-schema package - the other nice thing is that galaxy-schema code can now rely on various tool stuff without requiring dependency on any of the parser or runtime code.
This should also fix things for the new record types in #19377. I've introduced a type that can be used tools and is included schema for collection creation. The galaxy-tool-util-models packages can now be dependended on by galaxy-schema and galaxy-tool-util and these two packages do not need to depend on each other - either direction of that dependency would make me uncomfortable. xref
https://github.com/galaxyproject/galaxy/actions/runs/13704893929/job/38327692654?pr=19377
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.
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.
**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.
Fixes https://github.com/galaxyproject/galaxy/issues/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.
if we found a cached job in job_wrapper.prepare call (i.e. we had to do
a second round of the job search where we ignore the name match
requirement).
All other runners work via tha BaseJobRunner class that already does
this.
John Chilton