-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Idempotent start of the DynamoDB server #11815
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
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 26m 34s ⏱️ - 1h 16m 18s Results for commit 74e1c23. ± Comparison against base commit d08dfc5. This pull request removes 2668 tests.
♻️ This comment has been updated with latest results. |
@@ -79,6 +79,10 @@ def get() -> "DynamodbServer": | |||
def start_dynamodb(self) -> bool: | |||
"""Start the DynamoDB server.""" | |||
|
|||
# We want this method to be idempotent. | |||
if self.is_running() and self.is_up(): | |||
return True |
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.
Would this be invoked in a multi-threaded environment? If so, this should happen within the context of a mutex.
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.
Good point! I annotated the start_dynamodb
function as we already do with stop_dynamodb
. I think this should suffice.
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 ✔️
Motivation
This PR is a follow-up of #11789.
@HarshCasper noticed a bunch of logs like the following when loading a DDB state in a container without an initialized DDB provider (i.e., start LS and immediately load):
One can simply verify the behavior with:
This described scenario triggers these provider hooks in the following order:
on_after_state_load
, which starts the DDB server on a given port viaDynamodbServer::start_dynamodb
;on_before_start
, which also callsDynamodbServer::start_dynamodb
and tries to start DDB once again on the same port, causing the issue above.Changes
start_dynamoddb
that verifies if the thread is already running and healthy, making the function idempotent.ext pipeline to make sure persistence works correctly.