You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bug: Redis orphan lock timeout ignores expires_after_seconds and is always 10 seconds #8726
For contributors, human or agent. Comment here to claim this issue and wait for the assignment before opening a PR; if two PRs show up, the assignee's stays. AI-assisted work is welcome, say so in the PR and tell us how you verified it: run the tests yourself and paste what you saw, do not describe runs you did not do. Read AGENTS.md first, it has the commands and the rules the CI enforces. This goes into 3.41.0.
Expected Behaviour
The Redis orphan lock lives at most as long as the record: _orphan_lock_timeout = min(10, expires_after_seconds) uses the configured expires_after_seconds.
Current Behaviour
The value is computed in CachePersistenceLayer.__init__, before configure() has set expires_after_seconds, so it always sees the default 3600 and the timeout is always 10. With expires_after_seconds=2 the lock outlives the record by 8 seconds, and a request in that window that finds an orphaned record fails with IdempotencyInconsistentStateError instead of taking over.
For a public-API test, use a short expires_after_seconds, let a record go orphan, and assert the next call runs instead of raising.
Possible Solution
Compute the timeout where it is used, in _acquire_lock in aws_lambda_powertools/utilities/idempotency/persistence/redis.py, from self.expires_after_seconds at call time. Add a test with a fake Redis client asserting the ex value passed to set follows the configured expiry.
Item 9 of the Idempotency audit in #8603. No AWS resources needed, the Redis tests use a fake client.
For those interested in contributing, please leave a comment below so that we can assign the issue to you and make sure we don't duplicate efforts. If you have any further questions, please don't hesitate to ask below or on our Discord server.
Plan: compute the lock timeout in _acquire_lock from self.expires_after_seconds at call time (capped at 10s), instead of caching it in __init__ before configure() runs. I'll add a regression test that drives the public idempotent decorator with a fake Redis client, turns the stored record into an orphan, and asserts the ex passed to SET for the <key>:lock call is min(10, expires_after_seconds) (with a second case checking the 10s cap).
I'll wait for the assignment before opening the PR. AI-assisted, and I'll paste the actual test output in the PR.
Activity
powertools-for-aws-oss-automation commentedon Oct 31, 2026
Note
For those interested in contributing, please leave a comment below so that we can assign the issue to you and make sure we don't duplicate efforts. If you have any further questions, please don't hesitate to ask below or on our Discord server.
CJstate commentedon Nov 1, 2026
I'd like to take this one.
Plan: compute the lock timeout in
_acquire_lockfromself.expires_after_secondsat call time (capped at 10s), instead of caching it in__init__beforeconfigure()runs. I'll add a regression test that drives the publicidempotentdecorator with a fake Redis client, turns the stored record into an orphan, and asserts theexpassed toSETfor the<key>:lockcall ismin(10, expires_after_seconds)(with a second case checking the 10s cap).I'll wait for the assignment before opening the PR. AI-assisted, and I'll paste the actual test output in the PR.
leandrodamascena commentedon Nov 1, 2026
@CJstate it's yours, assigning you now. Go ahead with the PR, and say in the description how you ran the tests.