microsoft / microsoft/vscode-documentdb

Persist discovery-source provenance when saving connections

Open
#931 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement needs-triage
Dominant language
TypeScript
Stars
31
Forks
22
Avg merge
2d 20h
Merged PRs (30d)
21

Description

Problem

Add to Connections currently converts a cluster from Service Discovery or Azure Resources into a generic Connections View record primarily through EphemeralClusterCredentials. Authentication and connection details can be persisted, but provider-owned resource provenance carried by the source model is generally lost.

For Azure DocumentDB resources, this includes information such as:

  • the canonical ARM resource ID
  • tenant, subscription, and Azure cloud/environment context
  • resource group and resource name (or enough stable information to derive them)
  • source/provider identity needed to reacquire current ARM data
  • optional display metadata such as region, if we define its refresh and staleness semantics

Equivalent provenance exists for other providers. For example, Atlas has organization/project/cluster identifiers, while Kubernetes has context/namespace/service identity. The contract must be extensible rather than Azure-specific.

Once the connection is saved, losing this provenance prevents or complicates source-aware capabilities such as:

  • Open Azure DocumentDB in Portal or the equivalent provider portal
  • refreshing current resource metadata
  • provider-specific diagnostics and remediation
  • reconnecting a saved item to its discovery source without guessing from the hostname or connection string
  • preserving source context for later commands

The managed-identity work exposed a related symptom: authentication selected on a discovered Azure node is held in CredentialCache, while later getCredentials() calls rebuild data from ARM. Copy and save operations can therefore lose the selected identity. Authentication state and source provenance are separate concerns, but they need a coherent boundary.

Design requirements

  • Define a typed, versionable, provider-neutral provenance contract in connection properties, with provider-specific payloads or extension points.
  • Preserve stable source identity rather than treating mutable ARM/Atlas/Kubernetes snapshots as authoritative forever.
  • Define which values are persisted, which are derived, and which must be refreshed from the provider.
  • Keep provenance separate from authentication configuration and credential secrets.
  • Never persist access tokens, passwords, Atlas API secrets, connection strings with embedded credentials, or other provider credentials in non-secret properties.
  • Include enough Azure context to resolve the resource in the correct tenant, subscription, and cloud, including sovereign/custom-cloud considerations.
  • Preserve unknown provider metadata safely across load/save where practical, so adding a provider does not require central code changes for every field.
  • Define behavior when the provider extension is unavailable, the account is signed out, or the original resource has been deleted.
  • Define whether provenance participates in duplicate detection and how manually created connections remain source-agnostic.
  • Keep the storage change backward compatible; older records without provenance must continue to work.

Acceptance criteria

  • Saving an Azure DocumentDB vCore cluster from both Service Discovery and Azure Resources preserves a canonical link to the original ARM resource.
  • A saved Azure-backed connection can support an Open in Azure Portal command without rediscovering or inferring the resource from its hostname.
  • Saving an Atlas-discovered connection preserves enough non-secret provider identity for an equivalent provider action.
  • The design documents the minimum contract for additional discovery providers, including Kubernetes and future plugins.
  • Authentication method/configuration continues to round-trip independently of provenance.
  • Manual connections and existing persisted connections without provenance continue to load and connect normally.
  • Focused tests cover provider metadata round-trip, unknown/absent provenance, secret exclusion, and at least Azure plus one non-Azure provider.

Relationship to Copy Connection String

This work should establish the durable source/authentication boundary used by saved connections and will help scope Copy Connection String behavior. It will not automatically fix Copy invoked directly on an unsaved discovery/resource node; that command still needs a credential-resolution contract that combines fresh provider data with any in-memory authentication selection.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the Add to Connections flow, EphemeralClusterCredentials, CredentialCache, and later getCredentials() calls. Map how saved connection properties currently round-trip for Azure, Atlas, and Kubernetes sources, keeping authentication separate from provenance. Done means a versioned provider-neutral contract, backward-compatible persistence, secret exclusion, and focused round-trip tests for Azure and another provider.

Written by the indexing model from the issue text.

Assessment

Tech stack
azure, kubernetes, mongodb, typescript
Domain
backend, databases, devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.