Lambda: fix store typing for serialization by bentsku · Pull Request #13707 · localstack/localstack

bentsku · 2026-02-05T20:39:45Z

Motivation

This PR improves Lambda typing to support more serialization frameworks.

Changes

update VersionFunctionConfiguration to use the proper casing for CapacityProviderConfig: the TODO that was there was because the code was overriding the TypeDict definition as it was already declared in the scope 😬 also updated all usage of this attribute
make a lot of field have the proper type hint of None Union because it gets values straight from the provider requests, and those values can be None (caught by the serialization framework with real values)
use subclass for code: serialization framework does not support parent class type hint / polymorphism
move the instance_id hack in the on_after_state_load logic as we're already iterating over all Function to avoid putting this on the serialization framework

Tests

Test Results - Preflight, Unit

23 114 tests ±0 21 255 ✅ ±0 6m 17s ⏱️ ±0s
1 suites ±0 1 859 💤 ±0
1 files ±0 0 ❌ ±0

Results for commit 2ace1c8. ± Comparison against base commit 4f689f3.

♻️ This comment has been updated with latest results.

github-actions · 2026-02-05T21:04:08Z

Test Results (amd64) - Acceptance

7 tests ±0 5 ✅ ±0 3m 3s ⏱️ -1s
1 suites ±0 2 💤 ±0
1 files ±0 0 ❌ ±0

Results for commit 2ace1c8. ± Comparison against base commit 4f689f3.

♻️ This comment has been updated with latest results.

github-actions · 2026-02-05T21:33:12Z

Test Results (amd64) - Integration, Bootstrap

5 files 5 suites 2h 0m 35s ⏱️
3 786 tests 3 548 ✅ 238 💤 0 ❌
3 792 runs 3 548 ✅ 244 💤 0 ❌

Results for commit 2ace1c8.

♻️ This comment has been updated with latest results.

github-actions · 2026-02-05T21:36:43Z

LocalStack Community integration with Pro

2 files ± 0 2 suites ±0 1h 29m 21s ⏱️ - 27m 57s
3 762 tests - 1 436 3 520 ✅ - 1 327 242 💤 - 109 0 ❌ ±0
3 764 runs - 1 436 3 520 ✅ - 1 327 244 💤 - 109 0 ❌ ±0

Results for commit 2ace1c8. ± Comparison against base commit 4f689f3.

This pull request removes 1436 tests.

tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_lambda_dynamodb
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_opensearch_crud
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_search_books
tests.aws.scenario.bookstore.test_bookstore.TestBookstoreApplication ‑ test_setup
tests.aws.scenario.kinesis_firehose.test_kinesis_firehose.TestKinesisFirehoseScenario ‑ test_kinesis_firehose_s3
tests.aws.scenario.lambda_destination.test_lambda_destination_scenario.TestLambdaDestinationScenario ‑ test_destination_sns
tests.aws.scenario.lambda_destination.test_lambda_destination_scenario.TestLambdaDestinationScenario ‑ test_infra
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_prefill_dynamodb_table
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_stepfunctions_input_recipient_list[step_function_input0-SUCCEEDED]
tests.aws.scenario.loan_broker.test_loan_broker.TestLoanBrokerScenario ‑ test_stepfunctions_input_recipient_list[step_function_input1-SUCCEEDED]
…

♻️ This comment has been updated with latest results.

joe4dev

Thank you for pushing Lambda towards Avro Persistence 🚀

My main concern is regarding the HACK of serializing the volatile instance_id (see comment). I would like to hear @dfangl's thoughts on that one.

joe4dev · 2026-02-06T16:06:45Z

localstack-core/localstack/services/lambda_/invocation/lambda_models.py

-    working_directory: str
-    command: list[str] = dataclasses.field(default_factory=list)
-    entrypoint: list[str] = dataclasses.field(default_factory=list)
+    working_directory: str | None


Good catch. Absolutely right that these can be None given the value is taken from the request via .get() here.

@dfangl Was the goal with the non-None types here to enforce providing a default case, or did we miss this?

I think we missed it. None values probably make sense here, as they connote a special meaning (it's not overridden to be empty, it's just not specified), in comparison to an empty list.

joe4dev · 2026-02-06T16:07:22Z

localstack-core/localstack/services/lambda_/invocation/lambda_models.py

-    license_info: str
-    compatible_runtimes: list[Runtime]
-    compatible_architectures: list[Architecture]
+    # we need to use Union types as inheritance is not supported by serialization framework


praise: Thanks for the clarifying comment. Good to know.

joe4dev · 2026-02-06T16:44:45Z

localstack-core/localstack/services/lambda_/provider.py

+                    # A LocalStack restart or persistence load should create a new instance id.
+                    # Used for retaining invoke queues across version updates for $LATEST, but
+                    # separate unrelated instances.
+                    fn.instance_id = short_uid()


I am a little concerned that storing the ephemeral and internal instance_id in the model violates the assumption:

The instance id MUST be unique to the function and a given LocalStack instance

While this on_after_state_load approach fixes uniqueness for persistence loading, I wonder what happens when loading a CloudPod 🤔 . Does the instance_id get fixed there?

There might be a (small) chance to re-create the ugly race condition fixed in #10831 when deleting a function immediately followed by loading that same function from a CloudPod. wdyt @dfangl

What alternatives do we have?

Remove instance_id from the models and store it in the service (discussed here)

Ensure loading a Pod/State containing a Lambda function resets the instance_id

Offer some kind of @ignore annotation to skip serialization for volatile fields

🤞

...

Loading a Cloud Pod also triggers this hook 👍 so I don’t think this would be an issue? Except if we merge state, like restoring only functions in a specific account, but I don’t think this has been implemented yet, and the current logic would probably fail anyway?

if this is really an issue, I can try to write custom code to create a special class that would change value every time it’s restored, but that feels like abusing the system. Having the attribute somewhere else would be better

I think it makes sense to leave it here, we do not support partial state loads anyway I think, and will always reload everything.
We have to keep in mind that the instance id now ends up in the state and gets overridden at load - my only fear is that it will bite us at some point if we forget about resetting it.

dfangl

Thanks for tackling this! My only concern is the instance_id and what happens if we don't properly reset it after restoration, but for now this seems fine.

dfangl · 2026-02-10T15:18:16Z

localstack-core/localstack/services/lambda_/invocation/lambda_models.py

-    working_directory: str
-    command: list[str] = dataclasses.field(default_factory=list)
-    entrypoint: list[str] = dataclasses.field(default_factory=list)
+    working_directory: str | None


I think we missed it. None values probably make sense here, as they connote a special meaning (it's not overridden to be empty, it's just not specified), in comparison to an empty list.

dfangl · 2026-02-10T15:21:29Z

localstack-core/localstack/services/lambda_/provider.py

+                    # A LocalStack restart or persistence load should create a new instance id.
+                    # Used for retaining invoke queues across version updates for $LATEST, but
+                    # separate unrelated instances.
+                    fn.instance_id = short_uid()


I think it makes sense to leave it here, we do not support partial state loads anyway I think, and will always reload everything.
We have to keep in mind that the instance id now ends up in the state and gets overridden at load - my only fear is that it will bite us at some point if we forget about resetting it.

bentsku · 2026-02-10T15:30:30Z

My only concern is the instance_id and what happens if we don't properly reset it after restoration, but for now this seems fine.

Agreed, I think it would make sense for this field to be a "runtime variable" and having it live in some kind of global object outside the state, that would probably simplify things a bit?

Thanks a lot for your reviews 🙏

dfangl · 2026-02-10T15:36:56Z

Agreed, I think it would make sense for this field to be a "runtime variable" and having it live in some kind of global object outside the state, that would probably simplify things a bit?

Maybe, let's keep this in mind, but I would not change it in this PR honestly, we might not catch all implications, and this should make it in!

bentsku added this to the 4.14 milestone Feb 5, 2026

bentsku self-assigned this Feb 5, 2026

bentsku force-pushed the avro-lambda-store branch from c735bfd to 75a148b Compare February 6, 2026 09:12

bentsku marked this pull request as ready for review February 6, 2026 10:54

bentsku requested review from dfangl, dominikschubert, gregfurman and joe4dev as code owners February 6, 2026 10:54

joe4dev reviewed Feb 6, 2026

View reviewed changes

bentsku added 4 commits February 9, 2026 12:03

rework model + fix assignment

e2e11c4

more store improvements + instance_id logic

137869c

fix store typing to be more in line with reality

ce3b4f9

fix capacity_provider_config dataclass

2ace1c8

bentsku force-pushed the avro-lambda-store branch from 75a148b to 2ace1c8 Compare February 9, 2026 11:04

bentsku assigned dfangl Feb 9, 2026

dfangl approved these changes Feb 10, 2026

View reviewed changes

bentsku mentioned this pull request Feb 10, 2026

tests: run store checks in Community against Pro workflow #13721

Merged

bentsku merged commit f974d16 into main Feb 10, 2026
41 checks passed

bentsku deleted the avro-lambda-store branch February 10, 2026 19:10

Uh oh!

Conversation

bentsku commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Changes

Tests

Related

Uh oh!

github-actions bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results - Preflight, Unit

Uh oh!

github-actions bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results (amd64) - Acceptance

Uh oh!

github-actions bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results (amd64) - Integration, Bootstrap

Uh oh!

github-actions bot commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

LocalStack Community integration with Pro

Uh oh!

joe4dev left a comment

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!

bentsku Feb 6, 2026 • 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!

dfangl left a comment

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!

bentsku commented Feb 10, 2026

Uh oh!

dfangl commented Feb 10, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bentsku commented Feb 5, 2026 •

edited

Loading

github-actions bot commented Feb 5, 2026 •

edited

Loading

github-actions bot commented Feb 5, 2026 •

edited

Loading

github-actions bot commented Feb 5, 2026 •

edited

Loading

github-actions bot commented Feb 5, 2026 •

edited

Loading

bentsku Feb 6, 2026 •

edited

Loading