Summary

Since 2.1.0 (CDRIVER-5638), libmongoc puts the container metadata at the top level of the handshake client document as client.container. The handshake spec puts it at client.env.container. Any client running in Kubernetes or Docker sends a handshake with an unexpected top-level field.

Expected (spec)

Handshake spec: the schema nests

{{container: {runtime, orchestrator}}} 

inside client.env, and the Container section says "Container runtime information is captured in client.env.container".

client: {
  driver: {...}, os: {...},
  env: {
    container: { runtime: "docker", orchestrator: "kubernetes" }
  }
}

Actual

_mongoc_handshake_build_doc_with_application in src/libmongoc/src/mongoc/mongoc-handshake.c appends container as a sibling of env:

if (env_name, then (kv ("env", doc (...)))),
if (md->kubernetes || md->docker,
    then (kv ("container", doc (... "runtime" ... "orchestrator" ...)))))

So a client with KUBERNETES_SERVICE_HOST set sends:

client: { driver: {...}, os: {...}, container: { orchestrator: "kubernetes" } }

Impact

• Affects every libmongoc release from 2.1.0 through 2.5.5, and current master. 2.0.2 has no container metadata.
• Any server-side or proxy component that strictly validates the handshake document rejects or flags the unknown top-level container field. This was seen in the wild: connections from mongoc / mongocxx 2.5.5 / 4.3.0 clients running in Kubernetes were flagged by monguard as having an unexpected client metadata field.
• The container metadata is not where the spec says it is, so it cannot be consumed by anything that reads client.env.container.

Cause

Introduced in f142c61383 (CDRIVER-5638, #2016). The new test test_aws_and_container (in test-mongoc-handshake.c) asserts container.orchestrator as a top-level path, so it encodes the incorrect shape and passes. Prose test 9 in the spec requires that both container and FaaS metadata are present in client.env.

Related

• CDRIVER-5638: introduced the bug
• DRIVERS-2830: spec change
• CXX-3074 depends on CDRIVER-5638. It's worth checking that mongo-cxx-driver has no separate copy of the issue.