Is it ever possible for this cache to become out of sync? Does the user ever have raw access to the MongoClient (where they could call client.close())?

Yes, the MonogClient is available at django.db.connection.connection, but I don't think it's our job to consider situations where the user does something unexpected like calling close().

Does Django (or Django apps) commonly use fork() or multiprocessing? If so we should consider clearing this cache in the child process. Perhaps using

if hasattr(os, "register_at_fork"):
    os.register_at_fork(after_in_child=clear_client_cache)

https://docs.python.org/3/library/os.html#os.register_at_fork:

It's not something I've had experience with. Google AI overview says:

Django, when deployed using WSGI servers like Gunicorn or uWSGI, operates in a prefork model. This means the server forks multiple worker processes to handle incoming requests concurrently. Each worker process runs independently, allowing Django to manage multiple requests simultaneously. However, directly using os.fork within a Django application is generally discouraged due to potential conflicts with Django's request handling and database connections. For managing background tasks or parallel processing, libraries like multiprocessing or task queues such as Celery are recommended instead of direct forking.

Okay sounds good to me. We can reevaluate if someone reports it as a problem.

Overriding close() to do nothing omits the call to validate_thread_sharing() in the superclass implementation. If it's important, we could add that here. There's currently a test failure without it.

Threading, connection sharing between threads... it's all not much I have experience with, so I'm not too confident about any of this. Perhaps you can help to educate me if any of it is obvious to you, Shane.
django/django@34e248e

I would skip those threaded tests since pymongo does not implement PEP 249. We intentionally want to always share the same client among all threads.

I believe the client is already shared among threads as it's stored in the DatabaseWrapper._connection_pools class variable.

The validate_thread_sharing() logic ensures that separate instances of DatabaseWrapper aren't accessed in separate threads. The use case for disabling this is to allow in-memory sqlite database connections being shared between multiple threads for Selenium tests (#2879). I'm doubtful that disabling this logic for MongoDB is appropriate, so unless you can say definitively, I'd suggest we leave it for now.

I don't know the answer to this.

What function calls this?

Normally DatabaseWrapper.close() but it's also called by some tests.