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