[soujasK]

Issue number: closes #8659

Summary

Changes

As agreed in #8659 (option 1): BasePersistenceLayer.configure() only applies the config on its first call, so functions sharing a persistence layer instance silently use the first function's IdempotencyConfig. It now remembers the settings it applied and emits a PowertoolsUserWarning when it's configured again with a config whose settings differ, pointing to one persistence layer per config.

• The comparison is on the settings the layer applies (event_key_jmespath, payload_validation_jmespath, jmespath_options, raise_on_no_idempotency_key, expires_after_seconds, use_local_cache, local_cache_max_items, hash_function), not on object identity, so @idempotent without a config (which creates a new IdempotencyConfig() per invocation) doesn't warn. lambda_context and response_hook aren't part of it since they're read per call.
• Behaviour is otherwise unchanged: the first config still wins.
• Docs: a warning admonition below the IdempotencyConfig options table.

Tests: one for the differing-config case (warns, first config's settings kept; fails without the change) and one checking that a new config with the same settings doesn't warn. tests/unit, tests/functional/idempotency and tests/functional/batch pass on Linux (Python 3.12), plus ruff, mypy, ty, bandit and xenon. The existing idempotency tests also pass with this warning turned into an error, so none of them reconfigure a layer with a different config.

User experience

Before: two idempotent functions sharing a persistence layer with different configs silently use the first function's settings, and can return another request's stored response.

After: the same setup emits a PowertoolsUserWarning telling you to use a separate persistence layer instance for each IdempotencyConfig.

---

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

[leandrodamascena]

Hi @soujasK, I saw you closed this one. No problem, I just want to understand what you'd prefer. The bug is real and triaged for 3.40.0, and I already worked on it on my side. Do you want to reopen so I review your PR, or should I open a new one myself? Either way is fine, just let me know.

[soujasK]

Reopening this. I closed it by mistake. I need a bit more time to test and validate it properly, so I'll update here once that's done.

[leandrodamascena]

Thanks @soujasK, and sorry this sat for two weeks, 3.40.0 shipped without it. I reviewed it today on top of develop and it's exactly option 1 from the issue: compare the applied settings, warn on a different config, first one still wins. Goes out in 3.41.0 instead, no need to rebase, you'll be in the release notes.

[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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.17%. Comparing base (d07a9c2) to head (5d39896).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #8664   +/-   ##
========================================
  Coverage    97.17%   97.17%           
========================================
  Files          323      323           
  Lines        16606    16612    +6     
  Branches      1504     1505    +1     
========================================
+ Hits         16137    16143    +6     
  Misses         328      328           
  Partials       141      141           

☔ 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.

[soujasK]

Yeah happy to contribute and thanks for the mention in release notes.if anything you can ping me.