feat: support for local Event invocation type #8590

monroeclinton · 2026-01-25T17:58:53Z

This PR is a continuation of the discussion from #6900, #510 (comment), and #749.

Which issue(s) does this change fix?

Why is this change necessary?

This is necessary to allow running Event invocation types locally to make development more pleasant.

How does it address the issue?

This PR uses ThreadPoolExecutor to create an executor that runs Event invocation types, allowing for non-blocking invocations.

What side effects does this change have?

Event invocations now return a response with a 202 status code.
Event invocations that have an invalid function return a 404 with ResourceNotFound.

Mandatory Checklist

PRs will only be reviewed after checklist is complete

Review the generative AI contribution guidelines
Add input/output type hints to new functions/methods
Write design document if needed (Do I need to write a design document?)
Write/update unit tests
Write/update integration tests
Write/update functional tests if needed
make pr passes
make update-reproducible-reqs if dependencies were changed
Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

monroeclinton · 2026-01-26T19:21:20Z

@reedham-aws could you retry rerunning the failed tests? Much appreciated

monroeclinton · 2026-01-27T20:22:30Z

@reedham-aws could I get workflow approval again? thanks

monroeclinton · 2026-01-27T21:51:54Z

@reedham-aws @vicheey thank you, looks like tests are passing. Let me know if there's anything I can do to help get this reviewed, or any feedback I can address

reedham-aws

The logic looks solid to me. I didn't think about it too hard, but one small concern I have is how we're testing some of this logic. I feel like we'd want to test that the threads are being executed and cleaned properly beyond the original return of the 202. I think this is difficult to test considering it's a different process, but I'm not too sure. Do you have any thoughts on this @monroeclinton?

Side note: I didn't have time today, but maybe tomorrow I will try it out using samdev to confirm it's doing as expected.

reedham-aws · 2026-01-27T23:46:26Z

tests/unit/local/lambda_service/test_local_lambda_http_service.py

            "",
            {
                "Content-Type": "application/json",
-                "X-Amz-Durable-Execution-Arn": "arn:aws:lambda:us-west-2:123456789012:function:test-function:$LATEST/durable-execution/test-123",


I don't quite follow what's happening here; why are we removing the durable execution ARN and changing the InvocationType to DryRun below?

I believe this test case is asserting that the Event (async) invocation returns a 202 status code. This test case mocks the invoke function to return that X-Amz-Durable-Execution-Arn header. Since this PR now runs the invoke function on a thread, we are unable to get the invoke response before returning the response with a 202 status code. Prior to this PR, passing Event invocation type (like this test does) will cause an exception (as would this test, if not for the mock), so I'm not entirely sure why this test case was included in the durable execution PR. Ideally we could retrieve the ARN and return it, I tried to reverse engineer the aws-durable-execution-emulator-x86_64 binary to see how the ARN is computed, but since the internal durable execution library uses Python 3.13 I couldn't fully disassemble it with pycdc.

For changing the InvocationType to Event below, since Event is now supported we need to pass in a different unsupported invocation type to test the error message when an unsupported invocation type is passed.

Makes sense.

I just realized that the below changing from Event to DryRun is a different method, which definitely cleared up some confusion 😆

reedham-aws · 2026-01-28T00:06:22Z

tests/unit/local/lambda_service/test_local_lambda_http_service.py

+    @patch("samcli.local.lambda_service.local_lambda_http_service.ThreadPoolExecutor")
+    @patch("samcli.local.lambda_service.local_lambda_http_service.LambdaErrorResponses")
+    def test_invoke_request_handler_async_invocation_function_not_found_returns_error(
+        self, lambda_error_responses_mock, executor_class_mock
+    ):
+        # Test that async invocation (Event type) returns error when function doesn't exist
+        executor_mock = Mock()
+        executor_class_mock.return_value = executor_mock
+
+        request_mock = Mock()
+        request_mock.get_data.return_value = b"{}"
+        request_mock.args = {}
+        request_mock.headers = {"X-Amz-Invocation-Type": "Event"}
+        local_lambda_http_service.request = request_mock
+
+        lambda_runner_mock = Mock()
+        lambda_runner_mock.get_function.side_effect = FunctionNotFound
+        lambda_error_responses_mock.resource_not_found.return_value = "function not found response"
+
+        service = LocalLambdaHttpService(lambda_runner=lambda_runner_mock, port=3000, host="localhost")
+
+        response = service._invoke_request_handler(function_name="NonExistentFunction")
+
+        # Verify error response is returned
+        self.assertEqual(response, "function not found response")
+        # Verify get_function was called to validate
+        lambda_runner_mock.get_function.assert_called_once_with("NonExistentFunction")
+        # Verify executor was NOT called since validation failed
+        executor_mock.submit.assert_not_called()
+        # Verify error response uses normalized function name
+        lambda_error_responses_mock.resource_not_found.assert_called_once_with("NonExistentFunction")
+
+    @patch("samcli.local.lambda_service.local_lambda_http_service.LOG")
+    @patch("samcli.local.lambda_service.local_lambda_http_service.ThreadPoolExecutor")
+    @patch("samcli.local.lambda_service.local_lambda_http_service.LambdaErrorResponses")
+    def test_invoke_request_handler_async_invocation_invalid_function_name_returns_error(
+        self, lambda_error_responses_mock, executor_class_mock, log_mock
+    ):
+        # Test that async invocation (Event type) returns error when function name is invalid
+        executor_mock = Mock()
+        executor_class_mock.return_value = executor_mock
+
+        request_mock = Mock()
+        request_mock.get_data.return_value = b"{}"
+        request_mock.args = {}
+        request_mock.headers = {"X-Amz-Invocation-Type": "Event"}
+        local_lambda_http_service.request = request_mock
+
+        lambda_runner_mock = Mock()
+        test_exception = InvalidFunctionNameException("Invalid function name format")
+        lambda_runner_mock.get_function.side_effect = test_exception
+        lambda_error_responses_mock.validation_exception.return_value = "validation error response"
+
+        service = LocalLambdaHttpService(lambda_runner=lambda_runner_mock, port=3000, host="localhost")
+
+        response = service._invoke_request_handler(function_name="Invalid@Function#Name")
+
+        # Verify error response is returned
+        self.assertEqual(response, "validation error response")
+        # Verify get_function was called to validate
+        lambda_runner_mock.get_function.assert_called_once_with("Invalid@Function#Name")
+        # Verify executor was NOT called since validation failed
+        executor_mock.submit.assert_not_called()
+        # Verify error was logged
+        log_mock.error.assert_called_once_with("Validation error: %s", "Invalid function name format")
+        # Verify validation exception was called with the error message
+        lambda_error_responses_mock.validation_exception.assert_called_once_with("Invalid function name format")


These tests feel superfluous considering we test the same things for synchronous events, but I think we can leave them to test if there's somehow an unintended divergence in the path of sync/async.

reedham-aws · 2026-01-28T00:34:00Z

tests/unit/local/lambdafn/test_runtime.py

        self.assertTrue(result)
+
+
+class TestLambdaRuntime_clean_runtime_containers(TestCase):


Are these tests related to changes in the PR? If so, could you explain why because I'm not following.

@reedham-aws I had to get the test coverage to 94%, after adding test coverage to my new lines it was around 93.96% if I recall correctly

monroeclinton · 2026-01-28T02:19:29Z

@reedham-aws I think that's a great idea for additional testing, I'll look more into testing the threads tomorrow

reedham-aws · 2026-01-28T16:51:49Z

Thank you very much for you contributions and responses @monroeclinton!

monroeclinton · 2026-01-29T03:39:32Z

@reedham-aws I went with using threading.Event flags and assertions that the invoke function finishes executing (i.e. does not block) after the 202 response being returned. I'm more than happy to explore different ideas for asserting the Event invocation functionality

2664b99

I was thinking about how best to assert cleanup of any threads, but since the LocalLambdaService is blocking, and only exits with SIGINT/SIGTERM, I think it's pretty much guaranteed that the threads will be cleaned up due to the ThreadPoolExecutor implementation

https://github.com/python/cpython/blob/1848ce61f349533ae5892a8c24c2e0e3c364fc8a/Lib/concurrent/futures/thread.py#L23

I had to bump test coverage more with:

80729fb

reedham-aws

Thank you for the changes, had one really minor nit.

I also tested the feature using samdev local start-lambda to see how it handled async events. Everything works how I expected; the server properly returns 202, but still executes after being enqueued. I tested by sending a stream of requests and got the responses immediately, and saw the invocation results properly stream in server side.

tests/unit/local/lambda_service/test_local_lambda_http_service.py

reedham-aws · 2026-01-29T23:29:05Z

I was thinking about how best to assert cleanup of any threads, but since the LocalLambdaService is blocking, and only exits with SIGINT/SIGTERM, I think it's pretty much guaranteed that the threads will be cleaned up due to the ThreadPoolExecutor implementation

https://github.com/python/cpython/blob/1848ce61f349533ae5892a8c24c2e0e3c364fc8a/Lib/concurrent/futures/thread.py#L23

Also, maybe we could add a comment to this effect where we do the self.executor.submit?

monroeclinton · 2026-01-30T14:51:49Z

@reedham-aws Thanks for the feedback, updated the test assertions and added a comment about ThreadPoolExecutor

reedham-aws · 2026-01-30T17:58:33Z

Thank you @monroeclinton for the attention to all my feedback! I will try to get another member of the team to review this PR so we can look at merging it.

bchampp · 2026-01-30T18:50:40Z

tests/integration/local/start_lambda/test_start_lambda.py


+    @pytest.mark.flaky(reruns=3)
+    @pytest.mark.timeout(timeout=300, method="thread")
+    def test_invoke_with_event_invocation_type(self):


We don't really test that the function itself actually ran here. It would be nice to capture the stdout from the invocation in case something between where the executor queues the invocation and actually running the function breaks.

bchampp · 2026-01-30T18:52:42Z

samcli/local/lambdafn/runtime.py

+                        f"invocation-type: {invocation_type} is not supported. "
+                        "Event and RequestResponse are only supported."


Suggested change

f"invocation-type: {invocation_type} is not supported. "

"Event and RequestResponse are only supported."

f"invocation-type: {invocation_type} is not supported. "

"Only Event and RequestResponse are supported"

bchampp · 2026-01-30T18:53:53Z

tests/integration/local/start_lambda/test_start_lambda_cdk.py

@@ -112,7 +112,7 @@ def test_invoke_with_log_type_not_None(self):
    def test_invoke_with_invocation_type_not_RequestResponse(self):


unrelated to this PR - this test feels like it would be more appropriate in just test_start_lambda.py. This file is intended to be CDK specific but has additional validation tests 🤔

bchampp · 2026-01-30T18:54:32Z

tests/unit/local/lambda_service/test_lambda_error_responses.py

        )

+    @patch("samcli.local.services.base_local_service.BaseLocalService.service_response")
+    def test_validation_exception(self, service_response_mock):


thank you 🫡

bchampp · 2026-01-30T18:58:49Z

samcli/local/lambda_service/local_lambda_http_service.py

+        try:
+            self._invoke_lambda(function_name=function_name, **kwargs)
+        except Exception as e:
+            LOG.error("Async invocation failed for function %s: %s", function_name, str(e), exc_info=True)


It makes sense to sink the exceptions like you're doing here, but how does this appear for the user? Do you have a screenshot of what it looks like when you try async invoking a function that has a syntax error (so the sandbox crashes)?

bchampp · 2026-01-30T19:01:14Z

samcli/local/lambda_service/local_lambda_http_service.py

+        stdout_stream_bytes = io.BytesIO()
+        stdout_stream_writer = StreamWriter(stdout_stream_string, stdout_stream_bytes, auto_flush=True)
+
+        normalized_function_name = normalize_sam_function_identifier(function_name)


Should we call the get_function() utility you added here instead?

monroeclinton requested a review from a team as a code owner January 25, 2026 17:58

github-actions bot added area/local/start-api sam local start-api command area/local/invoke sam local invoke command area/local/start-invoke pr/external stage/needs-triage Automatically applied to new issues and PRs, indicating they haven't been looked at. labels Jan 25, 2026

monroeclinton force-pushed the event-invocation-type branch from d46c1be to d65bf60 Compare January 25, 2026 20:50

feat: support for local Event invocation type

4860576

monroeclinton force-pushed the event-invocation-type branch from 8a8842c to 4860576 Compare January 26, 2026 23:59

reedham-aws reviewed Jan 28, 2026

View reviewed changes

monroeclinton requested a review from reedham-aws January 29, 2026 13:49

reedham-aws requested changes Jan 29, 2026

View reviewed changes

tests/unit/local/lambda_service/test_local_lambda_http_service.py Outdated Show resolved Hide resolved

monroeclinton force-pushed the event-invocation-type branch from 80729fb to c669cfd Compare January 30, 2026 14:41

monroeclinton added 2 commits January 30, 2026 09:47

test: assert that local lambda invoke function runs

455c288

test: lambda error responses

ddde6c7

monroeclinton force-pushed the event-invocation-type branch from c669cfd to ddde6c7 Compare January 30, 2026 14:50

monroeclinton requested a review from reedham-aws January 30, 2026 14:51

reedham-aws approved these changes Jan 30, 2026

View reviewed changes

bchampp reviewed Jan 30, 2026

View reviewed changes

		self.assertTrue(result)


		class TestLambdaRuntime_clean_runtime_containers(TestCase):

		f"invocation-type: {invocation_type} is not supported. "
		"Event and RequestResponse are only supported."

		@@ -112,7 +112,7 @@ def test_invoke_with_log_type_not_None(self):
		def test_invoke_with_invocation_type_not_RequestResponse(self):

feat: support for local Event invocation type #8590

Are you sure you want to change the base?

feat: support for local Event invocation type #8590

Uh oh!

Conversation

monroeclinton commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue(s) does this change fix?

Why is this change necessary?

How does it address the issue?

What side effects does this change have?

Mandatory Checklist

Uh oh!

monroeclinton commented Jan 26, 2026

Uh oh!

monroeclinton commented Jan 27, 2026

Uh oh!

monroeclinton commented Jan 27, 2026

Uh oh!

reedham-aws left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

monroeclinton commented Jan 28, 2026

Uh oh!

reedham-aws commented Jan 28, 2026

Uh oh!

monroeclinton commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

reedham-aws left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

reedham-aws commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

monroeclinton commented Jan 30, 2026

Uh oh!

reedham-aws commented Jan 30, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

monroeclinton commented Jan 25, 2026 •

edited

Loading

reedham-aws left a comment •

edited

Loading

monroeclinton commented Jan 29, 2026 •

edited

Loading

reedham-aws commented Jan 29, 2026 •

edited

Loading