fix(idempotency): Redis persistence layer reclaims live in-progress records as orphans, allowing concurrent double-execution

[Adityaj0]

Issue number

Fixes #8386

Summary

Fixes a race condition in RedisCachePersistenceLayer._put_in_progress_record() where a genuinely still-running in-progress record gets wrongly reclaimed as an "orphan" and overwritten, letting a second concurrent invocation with the same idempotency key execute the underlying function too — defeating idempotency (e.g. double-charging a customer).

Changes

_put_in_progress_record only guarded against a competing invocation when the existing record's in_progress_expiry_timestamp was set and still in the future:

if (
    idempotency_record.status == STATUS_CONSTANTS["INPROGRESS"]
    and idempotency_record.in_progress_expiry_timestamp
    and idempotency_record.in_progress_expiry_timestamp > int(now.timestamp() * 1000)
):
    raise IdempotencyItemAlreadyExistsError

When in_progress_expiry_timestamp is None, this guard is skipped entirely, and the code falls through to the orphan-reclaim branch, which unconditionally overwrites the record (no NX) — even though the record may represent a genuinely still-running invocation.

in_progress_expiry_timestamp is None whenever remaining_time_in_millis wasn't available when save_inprogress was called, which happens whenever IdempotencyConfig.register_lambda_context() was never invoked. This is the default/common case for idempotent_function — unlike the idempotent() handler decorator (which calls config.register_lambda_context(context)), idempotent_function's decorate() never calls it. So any typical @idempotent_function(...) usage (e.g. inside an SQS batch loop) hits this by default.

The fix:

if idempotency_record.status == STATUS_CONSTANTS["INPROGRESS"] and (
    idempotency_record.in_progress_expiry_timestamp is None
    or idempotency_record.in_progress_expiry_timestamp > int(now.timestamp() * 1000)
):
    raise IdempotencyItemAlreadyExistsError

When the expiry timestamp is missing, we now fail closed (treat it as still in progress) instead of falling through to orphan-reclaim — mirroring persistence/dynamodb.py, whose conditional-write expression requires attribute_exists(#in_progress_expiry) before allowing an expired-in-progress reclaim.

This only changes behavior for the specific case where in_progress_expiry_timestamp is None; the existing orphan-reclaim path for records that legitimately timed out (timestamp set and in the past) is unchanged.

User experience

Before this fix, using @idempotent_function with RedisCachePersistenceLayer/CachePersistenceLayer (without separately wiring register_lambda_context) could silently execute a decorated function twice for the same idempotency key under concurrent retries. After this fix, the second concurrent invocation is correctly rejected with IdempotencyItemAlreadyExistsError until the first one completes or its record's own TTL expires.

Checklist

• My changes are covered by tests
• I have added/updated the develop branch docs, if applicable — N/A, this is a bug fix with no behavior/API change for the documented, correct-usage path (it only changes behavior for a previously-unsafe implicit case)

Is this a breaking change?

NO. The existing orphan-reclaim path for records with a set, expired in_progress_expiry_timestamp is unchanged. Only the (previously unsafe) in_progress_expiry_timestamp is None case now fails closed instead of failing open.

Tests

Added test_redis_in_progress_record_missing_expiry_is_not_treated_as_orphan in tests/functional/idempotency/_redis/test_redis_layer.py. It fails against the pre-fix code (Failed: DID NOT RAISE IdempotencyItemAlreadyExistsError) and passes after the fix — verified by reverting the fix locally and re-running.

Full suite tests/functional/idempotency/_redis/test_redis_layer.py: 21 passed (independently re-verified).

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[boring-cyborg]

Thanks a lot for your first contribution! Please check out our contributing guidelines and don't hesitate to ask whatever you need.
In the meantime, check out the #python channel on our Powertools for AWS Lambda Discord: Invite link

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[leandrodamascena]

Thanks for finding and fixing this issue. I reproduced the double execution through the public idempotent_function and CachePersistenceLayer APIs and confirmed the fix works.

I pushed a follow-up commit with a deterministic concurrency test. It keeps the first invocation running, starts a second invocation with the same key, and verifies that the function executes only once while the second invocation receives IdempotencyAlreadyInProgressError.

I also updated the lower-level test to use a different contender record, so its assertion now proves that the original record was not overwritten, and fixed the formatting issue.

The fix and coverage now look correct to me. Thank you for working on this.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.65%. Comparing base (78fdd32) to head (ebaf4ac).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #8387      +/-   ##
===========================================
+ Coverage    96.64%   96.65%   +0.01%     
===========================================
  Files          296      296              
  Lines        14767    14767              
  Branches      1246     1246              
===========================================
+ Hits         14271    14273       +2     
+ Misses         361      359       -2     
  Partials       135      135              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.