has anyone come up with a better way for all your Lambda funcs to know the Sentry DSN & release hash other than having them as env vars? I’m realizing now that when I deploy a new fix or something, every function is updated just because the Sentry release changed, and the deploy takes forever as a result

Put it in SSM and load it directly in the function perhaps.

If the lambda does not update its version you would need to expire any cahced value in hot lambda. If using SSM for all lambdas you will hit 400 req/s limit, paid mode does not scale infinitely either. You could use a short use cache TTL though, maybe 30 seconds?

I think a cache on start makes sense here. It won't update if the function doesn't update, but that seems like desired behavior maybe?

@Simon Reilly can you explain further what you’re talking about? Are you saying that if I update lambda functions and have them staying warm with cloudwatch events then they won’t be updated ever?

yeah, I’m not familiar with this caching thing in Lambda either, can you elaborate? as for 400 req/s limit with SSM, I doubt that would ever happen if the Sentry release hash is only pulled from SSM on cold start

Yeah, it's fine for cold start i.e. initialize outside the handler. Specifically, the lambda context had a pointer to the latest alias. I believe if this alias is not updated to a new version Arn then your lambda will remain hot. So you cannot guarantee a cold start at deploy time if you do not version the code. This is my understanding anyway

@Simon Reilly Thanks for clarifying. That is a good point though about SSM. I will have to be careful there.

ah yeah, I see what you mean. since the function isn’t being updated, the old Sentry release that was memoized will be used until the function spins down

Yeah, sorry, that is far simpler explanation