After upgrading mongodb to v5+ getting a "com.mongodb.MongoTimeoutException: Timed out.." in spring boot tests

Disclaimer: There are a couple of questions for this exact exception, sadly none of those match my environment or circumstances (thus i think this question is unique)

In my case i have a:

• working setup that works reliable in the CI when using MongoDB v4
• test never fail and i use Azure Pipelines to orchestrate the services during test startup (as always)

Now, the only change i make is: changing out the image references from mongo:4-focal to mongo:7-jammy (or :5 or :6) in the CI . After that, the CI based tests all fail with:

Caused by: org.springframework.dao.DataAccessResourceFailureException: Timed out while waiting for a server that matches WritableServerSelector. Client view of cluster state is {type=UNKNOWN, servers=[{address=nosql:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketException: nosql}, caused by {java.net.UnknownHostException: nosql}}]

Caused by: com.mongodb.MongoTimeoutException: Timed out while waiting for a server that matches WritableServerSelector. Client view of cluster state is {type=UNKNOWN, servers=[{address=nosql:27017, type=UNKNOWN, state=CONNECTING, exception={com.mongodb.MongoSocketException: nosql}, caused by {java.net.UnknownHostException: nosql}}]

This is what makes the differences to the other question, since we:

• know the setup is working (DNS, NAT, port mapping and all the sorts)
• we know the tests are working entirely reliable and just upgrading mongodb beyond mongo4 does let them fail
• in production, v7 is working just fine

To make matters more complicated (and make an argument for CI setup issues) is that during local tests, we run a docker-compose based setup for all the services (mongodb NATing 27017 to 37017) as usual and using mongodb://test:test@localhost:37017/test?authSource=admin as the connection string. And it works just fine with mongo5/6/7 just fine running the same exact tests.

I could not imagine how the test-setup in the CI is broken and just changing the mongodb image from :4 to :7 reveals that, still, the local testing speaks against it in some form.

So here is my azure-pipelines setup

the tests are started with The java-jdk container that runs the SPRING_DATA_MONGODB_URI:'mongodb://test:test@nosql:27017/test?authSource=admin' while the test itself run within the openjdk container (thus within the same docker-network as the mongoDB, thus we can access the mongodb using the service name nosql)

The resources are setup in the pipeline

resources:
  containers:
    - container: openjdk
      image: java:21-jdk-bookworm
      env:
        SPRING_DATA_MONGODB_URI: 'mongodb://test:test@nosql:27017/test?authSource=admin'     
    - container: nosql
      image: mongo:7-jammy
      env:
        MONGO_INITDB_ROOT_USERNAME: test
        MONGO_INITDB_ROOT_PASSWORD: test
        MONGO_INITDB_DATABASE: test

The very same setup is done for postgres, for rabbitmq, for elasitsearch in the CI since years, and they all work the same way / same concept.

Just upgrading Mongodb in this setup fails it and i'am really.

My current ideas are, that the mongodb driver above 4 uses a different ethology when it thinks a hostname is used (some kind of cluster resolving thingy), while v4 does not do that. And locally it works since we use localhost and this is just a special case for the driver to always assume 127.0.0.1 and period.