testcontainers / testcontainers/testcontainers-python
cosmosdb: CosmosDBNoSQLEndpointContainer doesn't work with vnext-preview emulator image
还没有人认领这个 Issue。
- 主要语言
- Python
- 星标
- 2.3k
- 派生
- 386
- 平均合并
- 4 小时 40 分钟
- 30 天内合并 PR
- 1
描述
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
-
vnext defaults to HTTP — the standard image defaults to HTTPS, which is what
urland_wait_until_readyhardcode. vnext needs--protocol httpspassed as a command to opt into HTTPS. There is no way to configure this through the module. -
No Data Explorer on vnext —
_wait_until_ready()pollshttps://localhost:8081/_explorer/index.htmlas a readiness signal. vnext returns 400 on that path, so the check loops for 120s and times out. -
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 raisesdocker.errors.NotFound. -
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_successonly catchesServiceRequestError(connection-level errors), so it does not retry on 503. -
Endpoint discovery returns internal port — The emulator advertises
https://127.0.0.1:8081in its discovery response regardless of how ports are mapped. Usingbind_ports=Falsecauses 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
protocolparameter (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_successalone is sufficient. - Make
_download_cert()optional or catchNotFoundgracefully — for vnext there is no cert to download. - Add
CosmosHttpResponseErrorto 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
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 CosmosDBNoSQLEndpointContainer.start()、_wait_until_ready()、_download_cert() 和 _wait_for_query_success() 入手,然后使用 vnext-preview 镜像复现列出的失败。将其协议、就绪状态、证书、重试和端点发现行为与标准镜像进行比较。当容器无需子类 workaround 即可支持 vnext-preview 镜像,同时保留标准镜像行为时,即表示完成。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- azure, docker, python
- 领域
- backend, databases
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 52/100