Support Multiple Concurrent Runtime Interface Clients for Lambda Managed Instances

[sebsto]

AWS launched Lambda Managed Instance, i.e Lambda functions running on EC2 instances.

This comes with a major change in the programming model as function handlers are now allowed to run concurrently on the same machine (multiple in flight events being processed in parallel in the same execution environment). The maximum concurrency per runtime environment is controlled by the user.

This PR adds support for running multiple Runtime Interface Clients (RICs) concurrently when deployed on Lambda Managed Instances, enabling the runtime to handle multiple invocations simultaneously within a single execution environment.

Changes

• Modified LambdaRuntime._run() to spawn multiple RICs based on the AWS_LAMBDA_MAX_CONCURRENCY environment variable
• Each RIC runs in its own task, polling for and processing invocations independently
• Removed UnsafeTransfer and mark the handler() (and all the types in uses in various form) Sendable
• Added waitForAll() to ensure proper error propagation from all RIC tasks
• Improved logging with RIC identifiers (RIC=1 through RIC=N) for better observability

Context
Lambda Managed Instances support multi-concurrent invocations where multiple invocations execute simultaneously within the same execution environment. The runtime now detects the configured concurrency level and launches the appropriate number of RICs to handle concurrent requests efficiently.

When AWS_LAMBDA_MAX_CONCURRENCY is 1 or unset, the runtime maintains the existing single-threaded behavior for optimal performance on traditional Lambda deployments.

[czechboy0]

Oh interesting, you'd want to release a new major for this?

[sebsto]

@fabianfett @adam-fowler @0xTim what do you think ?
This PR enables the concurrent processing of events on the new Lambda Managed Instances, but comes at the cost of adding Sendable conformance to LambdaHandler and all the types it touches.
This would require a major version bump.

What alternatives do we have to not bring Sendable to LambdaHandler ? Or would it be possible to hide this behind an opt-in Trait without duplicating LambdaHandlers.swift, Lambda+Codable.swift, and Lambda+JSON.swift ?

[sebsto]

@czechboy0 If we choose this solution, a major version bump is needed because we change the public API (added Sendable to public types).
I'm still investigating solutions to support this without making changes in the public API

[fabianfett]

@sebsto would you mind linking the relevant AWS docs?

[sebsto]

@fabianfett

Lambda Managed Instances

https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html

The section about concurrency
https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html#lambda-managed-instances-concurrency-model

The MAX CONCURRENCY env variable
https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html

[fabianfett]

I'm not a fan of this approach for multiple reasons:

1. This pushes the burden of needing to care about concurrency to the users, who didn't have to worry about concurrency this far (because Sendability wasn't required), for a feature that I assume only a small percentage of users will use.
2. It removes one of Lambdas nicest features (which is request isolation). If one request now runs into an issue that leads to a crash, all requests are impacted.

Given that we can only fix 2 by spawning multiple processes, the only thang that we can solve within the scope of this repo is: 1.

Given that this pr would break API and warrant a new major, which as far as I understand, we don't want, I propose the following:

We introduce a new type LambdaManagedInstancesRuntime, which works mostly like the LambdaRuntime. However it requires the Handler to be a LambdaHandler & Sendable. This way we don't have to change the LambdaHandler protocol anyway. Internally the LambdaManagedInstancesRuntime can just spawn a taskGroup and create multiple LambdaRuntimes. For users, who want to use multiple concurrent Lambda runners inside a managed instance, can change their application to use LambdaManagedInstancesRuntime instead of LambdaRuntime. Only at this point do they need the Sendable requirement to their handler.

@sebsto wdyt?

[sebsto]

Thank you @fabianfett for the analysis and the suggestion.
Your suggestion is less intrusive indeed.
I will update this PR to reflect the proposed design.

[sebsto]

Closing this PR. I will open a new one with the alternative approach