Feature request: Invocation context manager

[ran-isenberg]

Use case

1. 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.
2. I want these variables to get cleaned automatically on every invocation
3. 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.
4. I want to have a simple get function to get these parameters by name.
5. I'd like to have some default function getters such as tenant id, username.

Solution/User Experience

A singleton class that has several functions:

1. store value - store(key: str, value: Any, should_log : bool)
2. get value - get(key)
3. get_tenant_id
4. get_username
5. store_tenant_id(tenant_id : str)
6. store_username(username: str)

Alternative solutions

No response

Acknowledgment

• [X] This feature request meets Lambda Powertools Tenets
• [X] Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

[heitorlessa]

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]

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]

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]

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]

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?

I didnt intend it as a multi-invocation session context, maybe that's the confusion.

[ran-isenberg]

renamed to invocation context manager to make it more accurate. @heitorlessa

[heitorlessa]

cc @dreamorosi @am29d as this was a similar ask in TS.