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)
Rollback (Vault.Rollback)
Reference parsing
Auth
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).
Why
Every test for
internal/vaultruns 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 —isCASConflictinvault.gomatches on exactly that string viavaultapi.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.vaultapi.ErrSecretNotFoundhandling) creates a new secret correctly.Rollback (
Vault.Rollback)GetMetadata+ nativeKVv2.Rollback(ctx, path, toVersion)actually reverts to the target version's data on a real KV v2 mount.InvalidStatefailure whenCurrentVersion < 2.Reference parsing
vault://mount/a/b/c/key) resolve against a real KV v2 engine mounted at a non-default path, not justsecret/.Auth
VAULT_ADDR+VAULT_TOKENresolution viavaultapi.DefaultConfig()/NewClientagainst a real Vault server, including TLS verification behavior (default config'sErrorfield surfaces environment issues like a malformedVAULT_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).