Skip to content

Real-world integration test: HashiCorp Vault #3

Description

@smiggleworth

Why

Every test for internal/vault runs against a hand-written fake (fakeVaultAPI) implementing a subset of *vaultapi.KVv2's method set. Nothing in this package has ever talked to a real Vault server. In particular, the CAS-conflict detection is based on string-matching an error message documented in Vault's API docs, not observed from a live server — that's the single biggest unverified assumption in this package.

What to verify against a real Vault server (KV v2)

Write path (Vault.WriteMany)

  • WithCheckAndSet(cas) actually produces an HTTP 400 response containing the substring "check-and-set" on a real version conflict — isCASConflict in vault.go matches on exactly that string via vaultapi.ResponseError.Errors, and if Vault's real wording differs (across Vault versions, or Vault Enterprise vs. OSS), every conflict would silently be misclassified as non-retryable and fail immediately instead of retrying.
  • Confirm this against at least two Vault versions if possible, since this is undocumented-as-a-contract string matching, not a typed SDK error.
  • Merge-and-write-once behavior against a real multi-key secret with existing sibling fields.
  • First-write-to-a-missing-path (vaultapi.ErrSecretNotFound handling) creates a new secret correctly.

Rollback (Vault.Rollback)

  • GetMetadata + native KVv2.Rollback(ctx, path, toVersion) actually reverts to the target version's data on a real KV v2 mount.
  • Correct InvalidState failure when CurrentVersion < 2.

Reference parsing

  • Multi-segment paths (vault://mount/a/b/c/key) resolve against a real KV v2 engine mounted at a non-default path, not just secret/.

Auth

  • VAULT_ADDR + VAULT_TOKEN resolution via vaultapi.DefaultConfig()/NewClient against a real Vault server, including TLS verification behavior (default config's Error field surfaces environment issues like a malformed VAULT_CACERT).

Scope

Needs a real Vault server (dev-mode is fine for most of this, but the CAS-conflict wording should ideally be checked against a non-dev-mode Vault release too, since dev mode's exact behavior could differ).

Metadata

Metadata

Assignees

No one assigned

    Labels

    help wantedExtra attention is neededtestingReal-world / integration verification work

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions