Skip to content
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

Make sure Dynamodb lock context handler doesn't swallow exceptions #36

Merged
merged 3 commits into from
May 14, 2020

Conversation

gregeinfrank
Copy link
Contributor

@gregeinfrank gregeinfrank commented May 14, 2020

Right now, the context handler we were using would swallow any exceptions thrown within its block, which made debugging really hard.

There's a related issue in their repo mohankishore/python_dynamodb_lock#426 but it's easy enough to just create a new contextmanager

Pull Request synchronized with Asana task

Copy link
Contributor

@ericwalton-asana ericwalton-asana left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice find! I dug around a bit but didn't find a solution for this.

LGTM, pending a few nitpicky things. I like the unit test, looks great.

@@ -7,12 +9,20 @@
dynamodb_resource = boto3.resource("dynamodb")


def dynamodb_lock(pull_request_id: str):
@contextmanager
def dynamodb_lock(pull_request_id: str, retry_timeout: Optional[timedelta] = None):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're here, could we rename the pull_request_id parameter? In at least one case we pass a commit_id for this.

from datetime import timedelta
from python_dynamodb_lock.python_dynamodb_lock import DynamoDBLockError # type: ignore
from test.impl.mock_dynamodb_test_case import MockDynamoDbTestCase
from src.dynamodb.lock import dynamodb_lock
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm don't know how much it actually matters, but the pep8 standard for imports is:

Imports should be grouped in the following order:

  1. Standard library imports.
  2. Related third party imports.
  3. Local application/library specific imports.
    You should put a blank line between each group of imports.

https://www.python.org/dev/peps/pep-0008/#imports

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm generally sticking to black for formatting, and since the ordering of these is generally pep8 compatible besides the blank line between, I think it's fine and consistent with the other files in the codebase

@gregeinfrank gregeinfrank merged commit b1c4963 into master May 14, 2020
@gregeinfrank gregeinfrank deleted the gregeinfrank-throw-lock-errors branch May 14, 2020 02:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants