Feature request: Invocation context manager

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 Tenets
Should this be considered in other Lambda Powertools languages? i.e. Java, TypeScript

@ran-isenberg

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!!

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.

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?

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.

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.

@heitorlessa

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

@dreamorosi

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

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.

@ran-isenberg

Hey @ran-isenberg, coming back here with some news.

We recently shipped Depends() for type-safe dependency injection in route handlers (#8128), and I believe it addresses the core of what you were asking for here. Let me breakdown this:

1. Store global variables accessible across layers without passing them around - Depends() does exactly this. You declare a dependency once and it's injected wherever you need it:

from typing import Annotated
from aws_lambda_powertools.event_handler import APIGatewayRestResolver, Depends

app = APIGatewayRestResolver()

def get_tenant_id() -> str:
    claims = app.current_event.request_context.authorizer.claims
    return claims["tenant_id"]

def get_username() -> str:
    claims = app.current_event.request_context.authorizer.claims
    return claims["username"]

@app.get("/orders")
def list_orders(
    tenant_id: Annotated[str, Depends(get_tenant_id)],
    username: Annotated[str, Depends(get_username)],
):
    # both available here, no manual passing needed
    ...

2. Automatic cleanup on every invocation - dependency results are scoped per invocation by design. No stale state leaking between invocations.

3. Selectively enrich the logger - you control this inside each dependency function. Log tenant_id but not the email? You can do:

def get_tenant_id() -> str:
    tenant_id = app.current_event.request_context.authorizer.claims["tenant_id"]
    logger.append_keys(tenant_id=tenant_id)  # this gets logged
    return tenant_id

def get_user_email() -> str:
    # no logger.append_keys here - email stays out of logs
    return app.current_event.request_context.authorizer.claims["email"]

4. Simple get by name - that's just a function parameter. tenant_id and username are right there in the handler signature, fully typed.

The key difference from a singleton InvocationContext is that Depends() gives you the same convenience but with full type safety - your IDE knows the types, mypy/ty catch mistakes, and the dependency graph is explicit rather than hidden behind a global dict.

I'm going to close this one as addressed. As always, if you feel there's still a gap we're not covering, let me know - your feedback has shaped a lot of what Powertools is today.

Warning

This issue is now closed. Please be mindful that future comments are hard for our team to see.
If you need more assistance, please either reopen the issue, or open a new issue referencing this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@leandrodamascena

@leandrodamascena sounds good :) I'll need to play around with it once it's out.

Navigation Menu

Repository navigation

Feature request: Invocation context manager #2068

Use case

Solution/User Experience

Alternative solutions

Acknowledgment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: Invocation context manager #2068

Description

Use case

Solution/User Experience

Alternative solutions

Acknowledgment

Activity

heitorlessa commented on Apr 4, 2023

ran-isenberg commented on Apr 4, 2023

sthulb commented on Apr 5, 2023

ran-isenberg commented on Apr 5, 2023

ran-isenberg commented on Apr 5, 2023

ran-isenberg commented on Apr 5, 2023

heitorlessa commented on Jun 23, 2023

dreamorosi commented on Feb 19, 2025

leandrodamascena commented on Apr 9, 2026

powertools-for-aws-oss-automation commented on Apr 9, 2026

ran-isenberg commented on Apr 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions