[Integration][AWS] - Fix ExpiredTokenException

[mk-armah]

Description

What

• Improved the mechanism for parallel fetching of AWS account resources.
• Fixed ExpiredTokenException by replacing the event-based caching system with a time-dependent caching mechanism. The new approach ensures that the role is reassumed and session credentials are refreshed when 80% of the session duration has been used.

Why

• The previous event-based caching system led to the ExpiredTokenException, causing session credentials to expire unexpectedly.
• Implementing a time-dependent caching mechanism ensures that session credentials are refreshed proactively, preventing disruptions.

How

• Replaced the resync-dependent caching system with a time-based cache that monitors the session expiry.
• Added logic to reassume the role and refresh credentials once 80% of the session duration has passed, improving session reliability.

Type of change

Please leave one option from the following and delete the rest:

• Bug fix (non-breaking change which fixes an issue)

All tests should be run against the port production environment(using a testing org).

Core testing checklist

• Integration able to create all default resources from scratch
• Resync finishes successfully
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Scheduled resync able to abort existing resync and start a new one
• Tested with at least 2 integrations from scratch
• Tested with Kafka and Polling event listeners
• Tested deletion of entities that don't pass the selector

Integration testing checklist

• Integration able to create all default resources from scratch
• Resync able to create entities
• Resync able to update entities
• Resync able to detect and delete entities
• Resync finishes successfully
• If new resource kind is added or updated in the integration, add example raw data, mapping and expected result to the examples folder in the integration directory.
• If resource kind is updated, run the integration with the example data and check if the expected result is achieved
• If new resource kind is added or updated, validate that live-events for that resource are working as expected
• Docs PR link here

Preflight checklist

• Handled rate limiting
• Handled pagination
• Implemented the code in async
• Support Multi account

Screenshots

Include screenshots from your environment showing how the resources of the integration will look.

API Documentation

Provide links to the API documentation used for this integration.

[PeyGis]

good job on using the sessionDuration in the assume role client. I left a comment on how the aiocache works for the ttl

[PeyGis]

I would like to understand what happens when the cache is cleared after the duration? And how is the simple Memory different from using FastAPIs event.attribute functionality?

i guess my question is, since you changed the approach from event based to time based, what happens to the assumed role credentials after the ttl?

Also after the cache is cleared, how does it manage the re-entry. Thus, after the first ttl duration has elapsed, we signal that the credentials needs to be refreshed. Now what happens after the second hour. how does the ttl behave?