[Investigation] Kubernetes discovery: directConnection vs replicaSet, and the hardcoded `rs0`

[tnaum-ms]

Tomasz discovered this during the review of #621 and would like to get clarity before we decide on any code change.

The connection string the Kubernetes discovery feature builds for discovered DocumentDB targets sets both directConnection=true and replicaSet=rs0, where rs0 is a hardcoded magic string. This raises a few open questions we want answered before touching code.

⚠️ Everything in the "Initial AI assessment" section below is an initial AI assessment generated during the review — it is context to investigate and confirm, not established fact. Please validate it (especially with the DocumentDB engine team) rather than treating it as ground truth.

Desired outcome of this issue

1. Clarity on the connection path — direct connection vs. replica set. Which is correct for Kubernetes-discovered targets, why, and should the user be allowed to choose between them (e.g. a toggle / setting / per-connection option) rather than us picking one unconditionally?
2. How to handle rs0 as a magic string. What should happen when it is incorrect (a deployment whose replica-set name is not rs0)? Options to weigh: drop it entirely, make it configurable, detect it, or rely on directConnection making it inert.
3. What does the DocumentDB engine team tell us about the behavior in general and about typical deployments — default replica-set naming, whether single-node deployments are advertised as a replica set, and how the driver treats directConnection=true combined with replicaSet.

➡️ Only once these questions are clarified will we decide how (or whether) to address this in code. This issue is investigation-only; no implementation should land until the above is answered.

---

Initial AI assessment (to be validated — not authoritative)

Where it comes from

buildDocumentDbConnectionParams() in src/plugins/service-kubernetes/kubernetesClient.ts unconditionally sets:

const params = new URLSearchParams();
params.set('directConnection', 'true');
params.set('authMechanism', 'SCRAM-SHA-256');
params.set('tls', 'true');
params.set('tlsAllowInvalidCertificates', 'true');
params.set('replicaSet', 'rs0');

These params are attached to every discovered target (DKO and generic) and to the auto-credential path.

Likely reasons rs0 is hardcoded (hypotheses)

1. It may be the DocumentDB Kubernetes Operator (DKO) default. DKO likely provisions the database as a single-node replica set named rs0 (the same rs0 convention MongoDB uses for a default RS), so hardcoding it would match the common case. Needs confirmation from the engine/operator team.
2. Discovery never connects to the database, so it cannot learn the real RS name. The feature only reads Kubernetes objects (Services, the DKO dbs CRD, Secrets); it deliberately avoids a DB round-trip (hello/rs.status()). So the actual replica-set name isn't available at discovery time, and the operator default is assumed.
3. It mirrors the canonical/ documented DocumentDB connection string used elsewhere (getting-started lab, DocumentDB Local):
   mongodb://…@127.0.0.1:10260/?directConnection=true&authMechanism=SCRAM-SHA-256&tls=true&tlsAllowInvalidCertificates=true&replicaSet=rs0

The tension worth confirming

directConnection=true and replicaSet=rs0 are semantically at odds:

• directConnection=true is there for a real reason here: it pins the driver to the single reachable endpoint (the LoadBalancer/NodePort address, or 127.0.0.1:<localPort> for a port-forward). Without it, the driver would attempt replica-set discovery and try to reach members by their internal pod DNS names (…svc.cluster.local), which are unreachable from the user's machine.
• replicaSet=rs0 asks for replica-set topology.

In the MongoDB driver these can conflict — some driver versions reject directConnection=true combined with replicaSet, others ignore replicaSet when directConnection wins. In practice, with directConnection=true the replicaSet value is probably inert, which may be why this has not surfaced as a bug despite looking contradictory. This driver behavior should be confirmed against the actual DocumentDB driver/version we ship.

Caveats of hardcoding (if confirmed)

• A deployment with a non-default RS name makes rs0 wrong — though directConnection=true likely neutralizes it, so it may still connect.
• It is a magic string with no named constant or comment explaining the rs0 convention, so it reads as arbitrary to a future maintainer.

Possible directions (do NOT implement yet — pending answers above)

• Confirm whether the DocumentDB driver tolerates directConnection=true + replicaSet; if it's inert, consider dropping replicaSet for the discovery path.
• If a replica-set path is genuinely needed for some deployments, consider letting the user choose direct vs. replica-set, and/or making the RS name configurable instead of hardcoded.
• At minimum, extract rs0 / the param set into a documented constant explaining the convention.

References

• PR feat(kubernetes): add multi-source service discovery #621 — feat(kubernetes): add multi-source service discovery
• src/plugins/service-kubernetes/kubernetesClient.ts — buildDocumentDbConnectionParams()
• Pre-merge review doc: docs/ai-and-plans/PRs/621-kubernetes-discovery/pre-merge-code-review.md