cosmosdb: CosmosDBNoSQLEndpointContainer doesn't work with vnext-preview emulator image

The CosmosDBNoSQLEndpointContainer was built for the standard Cosmos DB emulator image (latest tag). It does not work with the vnext-preview image (mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview), which is the newer Linux-native emulator

Both images serve the same NoSQL API, but vnext has different runtime behavior that breaks assumptions in the current module.

What breaks

1. vnext defaults to HTTP — the standard image defaults to HTTPS, which is what url and _wait_until_ready hardcode. vnext needs --protocol https passed as a command to opt into HTTPS. There is no way to configure this through the module.

2. No Data Explorer on vnext — _wait_until_ready() polls https://localhost:8081/_explorer/index.html as a readiness signal. vnext returns 400 on that path, so the check loops for 120s and times out.

3. No PEM certificate on vnext — start() calls _download_cert() looking for a file at the legacy Windows-style path inside the container. vnext does not write a cert there, so this raises docker.errors.NotFound.

4. 503s during startup are not retried — After the container is up, vnext returns CosmosHttpResponseError (503, "pgcosmos extension is still starting") for a few seconds before it can serve queries. _wait_for_query_success only catches ServiceRequestError (connection-level errors), so it does not retry on 503.

5. Endpoint discovery returns internal port — The emulator advertises https://127.0.0.1:8081 in its discovery response regardless of how ports are mapped. Using bind_ports=False causes the SDK to connect to the wrong port after discovery. Related: https://github.com/Azure/azure-cosmos-db-emulator-docker/issues/160

Current workaround

I wrote a subclass that overrides start(), _wait_until_ready(), and _wait_for_query_success() — it passes --protocol https as a command, skips the cert download and explorer check, and catches 503s during readiness polling. It works but depends on the internal class hierarchy, which makes it fragile.

Suggestion

Some ideas:

• Add a protocol parameter (http/https) to control the URL scheme and pass the right startup command for vnext.
• Make _wait_until_ready() skip the explorer URL check when it returns 400 or is not available. Relying on _wait_for_query_success alone is sufficient.
• Make _download_cert() optional or catch NotFound gracefully — for vnext there is no cert to download.
• Add CosmosHttpResponseError to the retry decorator in _wait_for_query_success.

Alternatively, a dedicated vnext-aware container class would keep things clean.

Versions

• testcontainers 4.14.2
• Python 3.13
• Image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator:vnext-preview

Commencez par CosmosDBNoSQLEndpointContainer.start(), _wait_until_ready(), _download_cert() et _wait_for_query_success(), puis reproduisez les échecs indiqués avec l’image vnext-preview. Comparez son comportement en matière de protocole, de disponibilité, de certificats, de nouvelles tentatives et de découverte des endpoints avec celui de l’image standard. Le travail est terminé lorsque le conteneur prend en charge l’image vnext-preview sans la sous-classe de contournement, tout en conservant le comportement de l’image standard.