testcontainers / testcontainers/testcontainers-python

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

未关闭
#1,024 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 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

  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 vnextstart() 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

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 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

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。