[Suraj1347]

Issue

Closes #8599

Summary

After a successful parameter or secret write, the provider's in-memory cache could continue returning the previous value until the cache expired.

Changes

• Added a private cache-invalidation helper to BaseProvider.
• Invalidate cached entries after successful SSM parameter writes.
• Invalidate cached entries after successful Secrets Manager updates or creation.
• Preserve the cache when a write fails.
• Added seven regression tests using mocked AWS responses.

Grouped and nested cache entries are intentionally not invalidated by this change; the implementation documents this limitation.

Verification

• Python compilation and static checks passed according to the implementation report.
• Standalone logic checks passed according to the implementation report.
• The repository's pytest regression tests have not yet been run because the required test dependencies were unavailable locally.
• Automated CI checks and maintainer review will provide further verification.

Acknowledgment

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.

[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
1 New issue
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

[Suraj1347]

I completed an additional review of the cache invalidation changes and confirmed coverage for cache keys with and without sdk_options. One scope limitation remains: grouped get_multiple cache entries are intentionally preserved after a successful write and may remain stale until expiry or a forced fetch. Would maintainers prefer to keep this limitation documented in this PR, or should the invalidation behavior also cover grouped entries? I have not made further changes and would appreciate guidance before expanding the scope.

[leandrodamascena]

Thanks @Suraj1347, this one is solid. I ran it against real Parameter Store and Secrets Manager with reads and writes inside the cache window: single values, decrypt=True entries, the batch path and the module-level functions all return what was just written, a failed put_parameter leaves the cache alone, and the create path for a new secret works too. Leaving grouped get_multiple entries untouched and saying so in the docstring is the right call.

Approving. This goes out in 3.39.0, so it will sit here for a while before I merge it. No rebase needed in the meantime, and you'll be credited in the release notes.