FWIW The version of this function we're using in production was.

def run_django_worker(*args: Any, **kwargs: Any) -> None:
    alias = "default"

    try:
        connections[alias].close()
    except Exception:
        logger.error(f"Worker could not get a connection to the database with alias {alias}")

    run_worker(*args, **kwargs)

The exception catching and logging was transient and didn't stop us from using a 16 worker queue to process a few 100k events per day

The django.setup() solution is likely better (but I don't understand it so can't offer feedback)

I just checked production (Heroku - unix) and get_start_method() was "fork". I know that simply executing run_worker() will not work in that environment due to the psycog issues with the DB connection from pre-fork.

(Maybe this explains the failing CI test?)

Yes, I just realized that db connections are also closed pre-fork in the rqworker management command.

I called django.setup() because the spawned process doesn't load the installed apps at all. This works fine when I manually tested it, but fails in unit test. Probably its because django.setup() is not setting up the project in testing environment which leads to the process setting up its own DB instance.

I'm currently using this django code for parallel test runner as a reference. I'll try to update the PR in a day or two.
https://github.com/django/django/blob/53719d6b5b745dd99b1ab9315afb242f706ebbf1/django/test/runner.py#L424-L432

Similar to @jackkinsella's comment, we need to use our own run_worker command that calls reset_db_connections before running the original run_worker command: