MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors

[pjonsson]

Latest HEAD on develop (commit 89fdb0d) gives me these errors:

/app/lib/python3.12/site-packages/gunicorn/workers/ggevent.py:38: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. It may also silently lead to incorrect behaviour on Python 3.7. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016. Modules that had direct imports (NOT patched): ['urllib3.util (/app/lib/python3.12/site-packages/urllib3/util/__init__.py)', 'urllib3.util.ssl_ (/app/lib/python3.12/site-packages/urllib3/util/ssl_.py)', 'botocore.httpsession (/app/lib/python3.12/site-packages/botocore/httpsession.py)'].
  monkey.patch_all()
[2025-12-19 10:32:56,252] [WARNING] Environment variable $AWS_DEFAULT_REGION not set.  (This warning can be ignored if all data is stored locally.)
[2025-12-19 10:38:17,699] [WARNING] Credentials in environment have expired. Creating a DummySession.
[2025-12-19 10:38:18,524] [WARNING] Failed to resolve driver datacube.plugins.io.read::netcdf
[2025-12-19 10:38:18,524] [WARNING] Error was: ModuleNotFoundError("No module named 'netCDF4'")
[2025-12-19 10:38:18,541] [ERROR] Error opening source dataset: s3://bucket/12/18/dataset/b02.tif
[2025-12-19 10:38:18,542] [WARNING] Ignoring Exception: maximum recursion depth exceeded

The AWS_DEFAULT_REGION warning has always been there (don't use AWS S3), the netCDF warnings are new for 1.9.x, and the monkeypatch warning/dummy session/maximum recursion depth exceeded started happening after commit eda5f2b.

Since there is an error opening the dataset, I'm not getting any images in TerriaMap pointing to the WMS service of OWS.

[SpacemanPaul]

I'm not sure what to make of this one. Such a weird commit for it to start from too.

Did you used to get the "Credentials in environment have expired. Creating a DummySession." error previously? It does look like the credential manager class has thread safety issues and may have been messed up by the Flask initialisation PR, which was the next merge AFTER eda5f2b.

Have you modified the arguments passed to Gunicorn (in Dockerfile) at all?

[pjonsson]

No, the credentials have worked before. Without having looked carefully, I'm guessing the boto import in the create_app file should be moved to under if TYPE_CHECKING, and any other things that import urllib3 should also be imported after Flask/Gunicorn has had a chance to initialize.

The only thing I have changed with the command line is increasing the number of workers, but I'm guessing that is not the cause of this issue.

[SpacemanPaul]

The only thing I have changed with the command line is increasing the number of workers, but I'm guessing that is not the cause of this issue.

If the cause is a race condition, more workers could make it worse, but it sounds like you are getting it pretty consistently.