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
### Motivation:
- We want to store different entities that are needed when executing a handler within the LambdaContext (Logger, EventLoop, ByteBufferAllocator, …)
- Currently the LambdaRuntimeClient creates the LambdaContext. Having the LambdaContext with the Logger, EventLoop and ByteBufferAllocator be created from the LambdaRuntimeClient feels to me too much for me.
- Conceptionally the Lambda control plane api call is “get next Invocation” (API naming)
### Changes:
- LambdaRuntimeClient responds with an Invocation and does not use the LambdaContext at all anymore.
- LambdaRunner creates the LambdaContext with the Invocation, Logger and EventLoop.
- LambdaContext has been renamed to Lambda.Context
- Lambda.Context is a class now, since it is conceptionally not a value type and might be passed around a lot
- Lambda.Context properties `traceId`, `invokedFunctionArn`, `deadline` are not optional anymore since they will be always set when executing a lambda
- Creating an Invocation can fail with LambdaRuntimeClientError.invocationMissingHeader(String), if non optional headers are not present
- the test MockLambdaServer and the performance test MockServer always return headers for deadline, traceId and function arn (static for now – could be changed with Behaviour flag?!)
### Open ends:
- we will need to build some kind of Deadline into the context (See also #9 - probably for a different PR)
- we have a stupid mapping between ByteBuffer and [UInt8] in the LambdaRunner for now (marked with two TODOs). I don’t want to change this in this PR since it will lead to huge merge conflicts down the road with the potentiall API changes we have in mind.
0 commit comments