Open
Description
Use case
- I want to store global variables so they can be fetched in multiple areas in my areas without having to explicitly passing them around into the inner functions.
- I want these variables to get cleaned automatically on every invocation
- I want to have the option to automatically add these variables the logger so they are logged. But i want to also have the option not to do that. for example: log tenant id, but dont log the user's email address.
- I want to have a simple get function to get these parameters by name.
- I'd like to have some default function getters such as tenant id, username.
Solution/User Experience
A singleton class that has several functions:
- store value - store(key: str, value: Any, should_log : bool)
- get value - get(key)
- get_tenant_id
- get_username
- store_tenant_id(tenant_id : str)
- store_username(username: str)
Alternative solutions
No response
Acknowledgment
- This feature request meets Lambda Powertools TenetsShould this be considered in other Lambda Powertools languages? i.e. Java, TypeScript
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Ideas
Milestone
Relationships
Development
No branches or pull requests
Activity
heitorlessa commentedon Apr 4, 2023
Thanks a lot for taking the time to create this feature request @ran-isenberg! Adding labels to hear from other customers, and adding to the bucket of ideas for now.
I understand the intent, and we're also seeing a resurgence of customers using threading and asyncio in Lambda - this can get trickier and difficult to set expectations if we're not careful (e.g., ContextVars).
Looking forward to hearing from more customers on this need, and solutions they're using today (e.g., global dict, global dataclass, etc.)
Thanks!!
ran-isenberg commentedon Apr 4, 2023
We have a global class (with a dict). The best practice as I see it, is that the handler inject the parameters straight after the input validation. Then, if you tigger multiple threads, they are all using the same instance with read only capabilities.
sthulb commentedon Apr 5, 2023
I have a few questions :)
How do you see this working?
Where would the storage be for the data it would pull in? or would you expect there to be multiple data providers in case someone wants to use Redis/DDB/SQL/?
What would the failure modes be? i.e. not being able to refresh the context, would you want to error the invoke?
ran-isenberg commentedon Apr 5, 2023
It's not intended for anything else other than input based session context. No DDB/Redis.. just plain in memory that is reset once the invocation is finished.
Handler gets input -> verifies input -> you extract tenant id, username etc. from the input/ auth header id token etc. , set it on the context and call the logic layer.
again, super simple, just intended to remove the need to pass these parameters into the logic layer and have globally accessible.
ran-isenberg commentedon Apr 5, 2023
I didnt intend it as a multi-invocation session context, maybe that's the confusion.
[-]Feature request: Session context manager[/-][+]Feature request: Invocation context manager[/+]ran-isenberg commentedon Apr 5, 2023
renamed to invocation context manager to make it more accurate. @heitorlessa
heitorlessa commentedon Jun 23, 2023
cc @dreamorosi @am29d as this was a similar ask in TS.
dreamorosi commentedon Feb 19, 2025
Just wanted to chime in here to share this year's roadmap for the Python version of Powertools for AWS Lambda.
At least for now, this type of feature is out of scope, not in small part for the lack of wider customer demand.
The feature request will stay open, if you're interested in us considering this, please add a 👍 to the original post and consider sharing your use case.