Skip to content

fix: store and return TableClass, SSESpecification, OnDemandThroughput#155

Merged
LeeroyHannigan merged 2 commits into
mainfrom
fix/config-fields-and-set-semantics
Jun 5, 2026
Merged

fix: store and return TableClass, SSESpecification, OnDemandThroughput#155
LeeroyHannigan merged 2 commits into
mainfrom
fix/config-fields-and-set-semantics

Conversation

@LeeroyHannigan

Copy link
Copy Markdown
Collaborator

What

Store and return TableClass, SSESpecification, and OnDemandThroughput fields through CreateTable, DescribeTable, and UpdateTable.

  • TableClass persists as text and is returned in TableClassSummary on describe
  • SSESpecification: { Enabled: true } returns SSEDescription with Status: ENABLED, SSEType: KMS, and a synthesized KMSMasterKeyArn
  • OnDemandThroughput persists MaxReadRequestUnits / MaxWriteRequestUnits and round-trips through create/update/describe
  • Adds OnDemandThroughput struct to core types and KMSMasterKeyArn field to SseDescription

These are passthrough fields only, no behavioral enforcement (no throttling, no encryption, no storage tiering).

Why

Applications that set these fields (CDK, Terraform, SDK calls) should not error out, and tools that read them back (drift detection, state reconciliation) should get what they expect.

Testing done

  • cargo fmt --all -- --check — clean
  • cargo clippy --all-targets -- -D warnings — clean
  • cargo test --workspace — all pass (5 new unit tests for serde round-trips)
  • New tests/test_config_fields.py — 6 integration tests covering create, describe, and update for all 3 fields (all pass against ExtendDB)
  • Full pytest suite: 763 passed, no new failures

Checklist

  • I have read CONTRIBUTING.md
  • All tests pass (cargo test --workspace)
  • Code is formatted (cargo fmt --check)
  • Clippy is clean (cargo clippy -- -W clippy::pedantic)
  • I have added or updated tests for new functionality
  • I have updated documentation if behavior changed
  • Breaking changes are noted below (if any)
  • If this changes the wire protocol, Storage trait, auth model, on-disk
    format, or public CLI surface, an RFC has been accepted or is linked
    below. Otherwise, an ADR captures the decision (link below).

ADR / RFC: n/a


By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache License 2.0 and I agree to the Developer Certificate of
Origin (DCO). See CONTRIBUTING.md for details.

Comment thread crates/core/src/types/table.rs

#[test]
fn sse_description_serializes_with_kms_arn() {
let sse = SseDescription {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does SSEDescription include InaccessibleEncryptionDateTime ? Should it? (Doesn't necessarily have to be part of this review, but it looks to be missing.)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed as we don't simulate inaccessible keys. The field would always be null. Can add later if a customer scenario requires it.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. Okay. It's part of the DDB public API model though, isn't it? I'm okay with taking care of it separately, but it's not clear to me that it can be left out from an API model conformance perspective. (Unless we are accepting it in the API but just ignoring it?)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just ignoring it, yes. Its completely pass through. We have no way to simulate a non-conformant KMS key. Because we don't do KMS encryption.

status: "ENABLED".to_string(),
sse_type: Some(SseType::KMS),
kms_master_key_arn: Some(format!(
"arn:aws:kms:us-east-1:{}:key/default",

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is region relevant here at all? Not for ExtendDB functionally, but would customers be surprised if they've configured to run in a different region?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely, nice catch. Forgot to remove this after changing it for testing.

@jcshepherd jcshepherd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks okay: couple minor questions.

@jcshepherd jcshepherd left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more question about the SSE thingie, but shouldn't block this.

@LeeroyHannigan LeeroyHannigan added this pull request to the merge queue Jun 5, 2026
Merged via the queue into main with commit 4f6590a Jun 5, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants