You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
WIP: This is a change that I would like to talk about. I don't want to make all the changes necessary for this to correctly work before we haven't talked about if this is something we want to pursue.
### Motivation:
- We want to store different entities that are needed when executing a handler within the LambdaContext (Logger, EventLoop, ByteBufferAllocator, …)
- Currently the LambdaRuntimeClient creates a LambdaContext. Having the LambdaContext though as a wrapper around EventLoopGroup the API becomes messy.
- Conceptionally the Lambda control plane api call is “get next Invocation” (API naming)
### Changes:
- LambdaContext has now a reference to the EventLoop (needed for changes down the road)
- LambdaContext properties `traceId`, `invokedFunctionArn`, `deadline` are not optional anymore since they will be always set when executing a lambda
- LambdaRuntimeClient responds with an Invocation and does not use the LambdaContext at all anymore.
- Added an LambdaRuntimeClientError.invocationMissingHeader(String) error
### Open ends:
- tests fail, since I made some properties that are always set during the actual Lambda invocation non optional
- we will need to build some kind of Deadline into the context
- Invocation is currently a struct and I'd assume copied four times with six internal Strings. Maybe we can make this faster by using an internal Storage class. (potentially 4 ref counts vs 24).
- I don’t know if Context really is a value type? grpc-swift has the context as class:
https://github.com/grpc/grpc-swift/blob/nio/Sources/GRPC/ServerCallContexts/ServerCallContext.swift
- What do you think about namespacing LambdaContext within Lambda so that we only have Context.
0 commit comments