fix(s3vectors): read EncryptionConfiguration with the CFn SseType / KmsKeyArn spellings

[go-to-k]

Summary

S3VectorsProvider read the vector bucket's encryption sub-keys as SSEType /
KMSKeyArn, which the AWS::S3Vectors::VectorBucket CFn registry schema and
CDK's CfnVectorBucket renderer never emit — both spell them SseType /
KmsKeyArn (verified live against cloudformation:describe-type and
aws-cdk-lib's generated renderer on 2026-08-09).

Both lookups were therefore permanently undefined, so CreateVectorBucket
shipped the account-default encryption instead of the requested
customer-managed KMS key. Deploy reported success; nothing surfaced the
divergence, because readCurrentState re-emitted the same wrong spellings, so
cdkd drift compared SSEType against SSEType and saw no drift while state
held the template's SseType.

What changed

• create() reads SseType / KmsKeyArn and maps them onto the SDK's
  sseType / kmsKeyArn.
• readCurrentState() emits SseType / KmsKeyArn (the CFn spelling), so
  state and the AWS-current snapshot compare on the same keys. The Class-1
  KMS-only guard on KmsKeyArn is preserved verbatim.
• Existing unit tests that pinned the wrong spellings were corrected; two new
  create-path tests pin the mapping.

Test plan

• vp run check / typecheck:test / build / test — 515 files, 8693 tests, 0 type errors.
• Revert probe: re-introducing SSEType / KMSKeyArn into the real
  provider makes the two new create tests fail (sseType: undefined), then
  restoring turns them green — the tests fail without the fix.
• Real AWS: the s3-vectors fixture now deploys a CMK-encrypted vector
  bucket and verify.sh asserts GetVectorBucket returns
  sseType=aws:kms plus the exact key ARN from the stack output. Run
  2026-08-09: all assertions green, destroy 2 deleted / 0 errors, 0 orphans
  (the CMK is asserted to be PendingDeletion, which is the only state AWS
  offers for a deleted key). Recorded in docs/_generated/integ-last-run.tsv.

Upgrade notes for existing stacks

Two consequences of the wire-format change that reviewers surfaced, both
recorded here rather than papered over:

1. A bucket created by the pre-fix binary stays wrongly encrypted. The bug
   was purely on the wire — the template and state.properties both already
   held SseType, so a post-upgrade cdkd deploy sees no diff and the bucket
   silently keeps the account-default encryption. EncryptionConfiguration is
   create-only, so only a replacement fixes it. After upgrading, run
   cdkd drift <stack>; a vector bucket that reports EncryptionConfiguration
   drift must be recreated.
2. cdkd drift reports two phantom rows on such a bucket (SSEType -> undefined plus SseType: undefined -> …), because the
   observedProperties baseline written by the old binary holds the old
   spellings while readCurrentState now emits the new ones. This does not
   self-heal: kickOffAutoRefreshObservedProperties skips any resource that
   already has a baseline (src/deployment/deploy-engine.ts:876), and
   EncryptionConfiguration is create-only so no UPDATE ever refreshes it —
   the rows persist on every subsequent run. Clear them with
   cdkd state refresh-observed <stack>, which overwrites the baseline
   unconditionally. drift --revert on those rows dead-ends in
   ResourceUpdateNotSupportedError (create-only), which is correct — see
   point 1 for the real remedy.

Notes

AWS::S3Vectors::VectorBucket is not in NESTED_KEY_TARGETS
(scripts/gen-nested-key-coverage.ts), and the critic could not have caught
this class anyway: the CFn key SseType lower-firsts cleanly to the SDK's
sseType, so the pass classifies it same-spelling and never looks at what
spelling the provider actually reads. Extending the critic to that blind spot
is tracked in (#1393).

Closes #1385

[github-actions]

🎉 This PR is included in version 0.278.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀