Repository navigation
fix(idempotency): use the record key for DynamoDB composite items - #8739
Conversation
Read the idempotency key from the sort key for composite tables. Replayed records then use the actual operation key for response hooks, local cache lookups and in-progress diagnostics. Cover both conditional-write response and get-item paths through the public decorator, retaining simple-key controls.
powertools-for-aws-oss-automation
Bot
added
the
size/L
boring-cyborg
Bot
added
documentation
|
Thanks for the PR and for filling in the verification section, that helps. Heads up that the review may take a few days: this goes into 3.41.0 and I review every PR against a real service before approving, one at a time. No need to rebase or ping in the meantime, I'll come back here. |
leandrodamascena
left a comment
leandrodamascena
left a comment
There was a problem hiding this comment.
Thanks @sumedh-aerram! I looked at the one-line change and then at the tests, and the tests are what made me comfortable: simple and composite tables, custom sort key name, cache on and off, replay without hitting DynamoDB again. Ran everything on top of today's develop, all green. Goes out in 3.41.0, no need to rebase, you'll be in the release notes.
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #8739 +/- ##
========================================
Coverage 97.18% 97.18%
========================================
Files 323 323
Lines 16562 16562
Branches 1497 1497
========================================
Hits 16096 16096
Misses 326 326
Partials 140 140 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Awesome work, congrats on your first merged pull request and thank you for helping improve everyone's experience! |
|
Awesome work, congrats on your first merged pull request and thank you for helping improve everyone's experience! |
Issue number:
closes #8724
Summary
Changes
Read
DataRecord.idempotency_keyfrom the sort key when DynamoDB uses a composite primary key. The partition key remains shared across operations; the sort key identifies the operation. This restores local-cache lookup of stored responses and gives response hooks and in-progress diagnostics the correct key.Add public-decorator tests across simple and composite schemas, including a custom sort-key name, both conditional-write returned items and get-item fallback, both local-cache settings for hooks, cache replay without extra DynamoDB requests, and in-progress diagnostics. Update response-hook docs and its example. Existing tests and event fixtures remain unchanged. No storage schema, public signature or dependency changes are introduced.
User experience
Previously, replaying a record created elsewhere cached it under the static partition key and never found it by operation key. Hooks also reported the shared partition key. Replays now cache and report the operation's own key. Simple primary-key tables keep their existing behavior.
Verification
AI assistants (Claude and Codex) helped investigate and implement this change. Local commands were executed and output inspected during development.
make -k pr ty: exit 0, 4026 passed, 73 skipped, 10 deselected; all 10 performance tests passed. Ruff, mypy (949 source files), ty, docs lint, security and complexity checks passed. Pre-commit hooks were also run explicitly on every changed file, including the new tests, and passed.make -k pr tyrepeated successfully (exit 0);make test-dependenciespassed all 15 Nox sessions on Python 3.12.14 with newly recreated environments. Independent review found no blocking defects and separately reran the 24 focused public-API cases successfully. The worktree remained clean. Optional broader cache/key-schema coverage was suggested; no defect was reproduced and existing tests were preserved.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.