-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
ESMv2: Fix UpdateEventSourceMapping request and batch size check for SQS #11637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@@ -637,7 +637,7 @@ def validate_and_set_batch_size(service: str, batch_size: Optional[int] = None) | |||
BATCH_SIZE_RANGES = { | |||
"kafka": (100, 10_000), | |||
"kinesis": (100, 10_000), | |||
"dynamodb": (100, 1_000), | |||
"dynamodb": (100, 10_000), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazon DynamoDB Streams – Default 100. Max 10,000.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gregfurman Can we trigger the ext pipeline here to check whether it breaks pipes?
(if urgent, better compromise at Pipes in preview rather than ESM)
elif service == "kafka": | ||
if set(mapping["Topics"]).intersection(request["Topics"]): | ||
# Check we are validating a CreateEventSourceMapping request | ||
if is_create_esm_request: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only validate the below checks if the request is a CreateEventSourceMapping
since this will check for duplicates etc.
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 20m 16s ⏱️ - 21m 19s Results for commit 2f897d1. ± Comparison against base commit f6d2d07. This pull request removes 927 tests.
♻️ This comment has been updated with latest results. |
727e8a7
to
2f897d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for the initial approach! There are definitely more improvements we need to make, like persisting the state of stream listeners, and more test for the various update states, but this should at least come close to the parity of the old implementation!
|
||
# We should stop() the worker since the delete() will remove the ESM from the state mapping. | ||
esm_worker.stop() | ||
# This will either create an EsmWorker in the CREATING state if enabled. Otherwise, the DISABLING state is set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment is a bit misleading, it will create an EsmWorker with the internal state of CREATING
, but the state in the store depends on the actual action we are taking. In the followups, we should discuss the state management of ESM workers, I am not a fan at all with the current approach, but good job making the best out of it!
Motivation
This PR addresses some regressions in ESM v2 parity when compared with ESM v1.
Changes
UpdateEventSourceMapping
requests now work -- where an update request will re-create a new ESM from scratch and overwrite the previous version with its new state.validate_event_source_mapping
has been extended to includeUpdateEventSourceMapping
requestsTesting
The following regressions have been remedied with the new changes:
test_event_source_mapping_default_batch_size
test_sqs_event_source_mapping_update
ext test runs: