rtyler opened a new issue, #6718: URL: https://github.com/apache/arrow-rs/issues/6718
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.** Most of the ObjectStore calls, at least in the AmazonS3 code, will invoke their [credential provider](https://github.com/apache/arrow-rs/blob/object_store_0.10.2/object_store/src/aws/client.rs#L655) on every method invocation. The current `get_credential(&self)` function signature3 works well when we assume low/zero-cost credential resolution. In the case of assuming an IAM role, as an example, there _is_ substantial cost insofar that an AWS STS API call must be made. There is obvious benefits of re-resolving credentials on every call, especially when tokens expire. I don't believe the non-mutable `CredentialProvider` allows for easy caching of expensive credential resolution however. **Describe the solution you'd like** In my use-case I want to cache repeated invocations to the same `CredentialProvider` in the same process for the appropriate amount of time dictated by the credential issued. For example, when a role is assumed in AWS there will be temporary credentials vended which come with an expiration. Every subsequent invocation of `get_credential(` _should_ return cached/stored temporary credentials on the `CredentialProvider` implementation _until_ those credentials expire, at which point they should be re-resolveed/assumed and an updated `Credential` should be cached/stored inside the `CredentialProvider`. :thinking: I _believe_ that `get_credential(&mut self)` on the trait would allow my implementations sufficient flexibility here. If this is an okay thing to do, I can pop out a PR for it <!-- A clear and concise description of what you want to happen. --> **Describe alternatives you've considered** Yucky statics external to the `CredentialProvider` in the process to act as a lookup table. :nauseated_face: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
