<!--- Provide a general summary of your changes in the Title above -->
Fix after release of swift-log 1.8.0
## Issue \#
<!--- If it fixes an issue, please link to the issue here -->
## Description of changes
<!--- Why is this change required? What problem does it solve? -->
## New/existing dependencies impact assessment, if applicable
<!--- No new dependencies were added to this change. -->
<!--- If any dependency was added / modified / removed,
THIRD-PARTY-LICENSES must be updated accordingly. -->
## Conventional Commits
<!--- Please use conventional commits to let us know what kind of change
this is.-->
<!--- More info can be found here:
https://www.conventionalcommits.org/en/v1.0.0/-->
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 license.
- Adjust notice, security reporting, code of conduct, contribution
process to the standard AWS documents
- Adjust GitHub issue templates to AWS standard ones.
- Adjust the license header in all source files
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
- Use the new Swift 6 `@available` macro to remove requirement on
`.platform` in Package.swift.
- DRY: define the swift settings once for all in `Package.swift`
### Motivation:
- Remove the requirement to build on macOS 15 in `Package.swift`. This
allows library builders and end users to be more flexible on their
dependency requirements.
- The code is optionally compiled on macOS 15 and Linux, but SPM don't
enforce it anymore.
- Avoid repeating ourself. Be sure the same settings are applied on all
targets.
### Modifications:
- Create a `var swiftSetting: [SwiftSettings]` and reuse it for all
targets.
- Use `AvailabilityMacro=LambdaSwift 2.0:macOS 15.0`
- Add this on top of the majority struct / classes
```swift
#if swift(>=6.1)
@available(LambdaSwift 2.0, *)
#endif
```
### Result:
When using Swift 6.1, there is no more SPM dependency on macOS 15
This PR implements a mechanism to propagate connection loss information
from the Lambda runtime client to the runtime loop, enabling termination
without backtrace when the connection to the Lambda control plane (or a
Mock Server) is lost.
The changes are:
- When the connection is lost,
`ChannelHandlerDelegate.channelInnactive()` now correctly calls
`resume(throwing:)` on the ending continuation, for all states
(`.waitingForNextInvocation ` and `.sentResponse`). This eliminates the
hangs on connection lost..
- I added top-level error handling on `LambdaRuntime._run()`
- Add a unit test to check that either
`LambdaruntimeError.connectionToControlPlaneLost`, a `ChannelError`, or
an `IOError` is thrown when the server closes the connection
re-implement MAX_INVOCATIONS and fix shell script
Fix https://github.com/swift-server/swift-aws-lambda-runtime/issues/377
### Motivation:
In v1, there was a script measuring the performance of the invocation
loop.
Re-instate this script to allow users and developers to measure the
performance impact of their changes.
### Modifications:
I re-implemented MAX_INVOCATIONS, to avoid the client looping against
the Mock Server. But this time, MAX_INVOCATIONS is handled on the
server, not on the client.
I slightly modified the script to work with v2 and the new MockServer.
### Result:
The script works.
This PR has a dependency on
https://github.com/swift-server/swift-aws-lambda-runtime/issues/465
This is a proposal to fix issue #507
**changes**
- `LambdaRuntime.init()` uses a `Mutex<Bool>` to make sure only one
instance is created
- `LambdaRuntime.init()` can now throw an error in case an instance
already exists (I did not use `fatalError()` to make it easier to test)
- All `convenience init()` methods catch possible errors instead of
re-throwing it to a void breaking the user-facing API
- Renamed existing `LambdaRuntimeError` to `LambdaRuntimeClientError`
- Introduced a new type `LambdaRuntimeError` to represent the double
initialization error
---------
Co-authored-by: Fabian Fett <fabianfett@apple.com>
Co-authored-by: Adam Fowler <adamfowler71@gmail.com>
We want that the runtime only depends on `FoundationEssentials` where
available (ie. on linux) to ensure small binary size.
### Motivation:
Smaller binary size is good for lambda deployment and cold-start times.
The runtime should only depend on `FoundationEssentials`.
### Modifications:
- replace `import Foundation` with `import FoundationEssentials` if
`FoundationEssentials` is available.
- I also applied the same treatment to tests to ensure that catch error
where tests run on linux and we use API that is only available in
`Foundation` which easily happens when you develop on macOS (where
always full `Foundation` is available).
### Result:
This should allow builds without linking full `Foundation`.
motivation: unique, accurate name
changes:
* rename project to SwiftAWSLambdaRuntime
* rename main module to AWSLambdaRuntime
* rename / simplify sample module names
* adjust readme and scripts
motivation: nicer apis, happier users
changes:
* use ByteBuffer + EventLoopFuture for core APIs instead of byte array and callbacks
* create three base protocols: ByteBufferLambdaHandler, EventLoopLambdaHandler and LambdaHandler
* abstract common encoding/decoding functionality into a EventLoopLambdaHandler, reducing most code from string/codable handlers
* only the highest level LambdaHandler is offloaded to a DispatchQueue, lower level is run on the same EventLoop as the core library
* refine encoding/decoding logic
* inline all the things
* adjust tests
* adjust api docs
* adjust readme
Motivation:
- As a developer I want to be able to know how much time I have left to execute my lambda, before it times out
Changes:
- storing the deadline on Context and Invocation
- added getRemainingTime() to Context which returns a TimeAmount
- Renamed `Invocation.deadline` to `Invocation.deadlineInMillisSinceEpoch` to better reflect
- fixed MockLambdaServer to not return “keep-alive” anymore
Co-authored-by: tom doron <tomer@apple.com>
### 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.
motivation: simpler concurrency, better tests
changes:
* ensure http client is called in a single-threaded manner and remove locks
* refactor test
* make mock server more robust
motivation: benchmark for comparison of warm/cold runs
changes:
* refactor configuration
* add mock server that can be used by perf tests
* add simple perf test script
* change redundant classes to structs, make remaining classes final
* make offloading opt-in
* safer locking
* fix format
Adam Fowler
Sébastien Stormacq
Tobias
Franz Busch
Fabian Fett
tomer doron
tom doron
Fabian Fett