Repository navigation
Feature request: Circuit breaker DynamoDB persistence, support single-table (composite key) reuse #8315
Description
Activity
Hi, I’m interested in contributing to this if it’s still available. I noticed this can mirror the existing Idempotency DynamoDBPersistenceLayer composite-key design. My plan would be to add optional sort_key_attr/static_pk_value support, keep current partition-key-only behavior unchanged, add Stubber-based functional tests for GetItem/PutItem/UpdateItem, and update the Circuit Breaker docs. If @Iamrodos is already working on it, I’m also happy to collaborate or pick another issue.
Reacted by rodosThanks a lot @Iamrodos. This makes sense and you're right about the current limitation.
CircuitBreakerDynamoDBPersistenceonly ever uses the partition key, so against a composite-key table every call would fail and the breaker would fail open on each invocation and never trip. Exactly what you described.One thing to watch when implementing: the circuit breaker doesn't only do
get_item. It also does a conditionalput_itemfor the half-open probe election and anupdate_itemon state changes. The composite key has to be threaded through all three paths (including the conditional-write key), not just the read, otherwise it'll half-work.@xiaoranwang1452 happy to have you collaborate with this issue. Please include Stubber-based tests for get/put/update in both modes and a docs update.
PR submitted #8316
@xiaoranwang1452 would appreciate your eye over it to ensure it meets the expectations of your use case.
Reacted by xiaoranwang1452- moved this from Triage to Coming soon in Powertools for AWS Lambda (Python)
on Jul 2, 2026 Warning
This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either reopen the issue, or open a new issue referencing this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.- added a commit that references this issue
on Jul 5, 2026 This is now released under 3.31.1 version!
Use case
CircuitBreakerDynamoDBPersistencelets us rename attributes but assumes a partition-key-only table. Our single-table design uses a composite key, and DynamoDB requires the sort key on every call so the persistence layer can't operate against it. It would be inert, failing open on every call (logged at WARNING) and never trips.Solution/User Experience
Match the Idempotency utility's
sort_key_attr+static_pk_value:sort_key_attrstays optional, omit it and behavior is unchanged (partition-key-only, as today). Only when you supply it does the layer write the composite key:static_pk_valueinto the partition, circuit name into the sort key. No separate table, consistent with the rest of Powertools.Happy to do a PR for this.
Alternative solution
A dedicated single-attribute table works but adds infra/IAM and breaks the single-table model, the same reason Idempotency added composite-key support.
Acknowledgment