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

Surprising behaviour in Client.table_exists #138

Open
darylweir opened this issue Sep 22, 2022 · 1 comment
Open

Surprising behaviour in Client.table_exists #138

darylweir opened this issue Sep 22, 2022 · 1 comment

Comments

@darylweir
Copy link

We use Table.exists as part of a health check for the containers in our application, which in turn calls Client.table_exists. Today we had a short outage when all health checks began failing. It turned out the Dynamo table had entered UPDATING status.

The implementation does the following:

async def table_exists(self, name: TableName) -> bool:
        try:
            description = await self.describe_table(name)
        except TableNotFound:
            return False

        return description.status is TableStatus.active

This feels like a bug to us: UPDATING is a valid state while a variety of operations are being applied to the table. So the code should do return description.status in [TableStatus.active, TableStatus.updating].

Thoughts?

@ojii
Copy link
Contributor

ojii commented Sep 26, 2022

@darylweir thank you for this report. I agree it would make sense for table_exists to also allow .updating. But there's probably also a use case (eg our test suite) for table_active that mirrors the behavior of the current table_exists. I'd be happy to accept a PR that improves this situation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants