Upgrade syntax using `pyupgrade --py36-plus` .
Manually drop several `six` imports.
Also:
- Remove broken pr_cache in scripts/bootstrap_history.py
- Fix broken prefix removal in lib/galaxy/tool_util/deps/mulled/mulled_build.py
Move galaxy.web.stack.database_heartbeat into galaxy.model - since it was the only thing in galaxy.web.stack that used galaxy.model at all and it didn't import anything else from galaxy.web.stack.
Once that was done, I refactored this whole package (galaxy.web.stack) into galaxy.web_stack. It doesn't use the framework setup or exported by the base galaxy.web package so it wouldn't seem to belong there. It also has very different dependencies than the rest of that. And finally and most importantly, this elimiantes almost all dependency from galaxy.jobs and galaxy.tools and galaxy.workflows to anything in galaxy.web.
and verify tasks get executed the expected number of times.
Since the part after the yield statement runs to early it
was shutting down the app(s) prematurely.
So far I don't think we have any messages that should survive
restarts. If we do at some point we should route them differently
(or change the existing worker to use ephemeral messages).
Unfortunately adding a third app doesn't seem to work.
In that case only the last 2 apps receive the control task.
I do know that this isn't a problem with real separate processes,
but I don't know what is causing this.
Occasionally we want to wait for a toolbox or data table
reload before continuing, so knowing when that's done
(=wait for the result) is helpful.
Getting the result of a task seems like a good idea,
we could use this for a whole lot of things.
One thing is targeting functions to (remote) handlers
that have access to information that web handlers don't,
like how busy a cluster is or which dependencies are
available or whether a handler is dead.
It's important to not set the DatabaseHeartbeat `server_name` prior to forking,
which we avoid be getting `server_name` from
`application_stack.app.config.server_name`.
`WorkerProcess.server_name` for uwsgi web processes will look like:
`main.web.1` and mules like `main.job-handlers.1` while webless workers
remain named `handler1`.
Nicola Soranzo