Repository navigation
fix(spanner): release transaction lock if inline begin fails - #18409
Merged
olavloite merged 1 commit intoSep 17, 2026
Merged
olavloite merged 1 commit into
olavloite merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces try-finally blocks in both the synchronous and asynchronous implementations of execute_update and batch_update within the Google Cloud Spanner transaction modules. This ensures that the transaction lock is safely released if an error occurs during an inline begin. Unit tests have been added to verify that the lock is released upon failure, and mockserver has been added to the noxfile. There are no review comments, so I have no feedback to provide.
Sorry, something went wrong.
When execute_update() or batch_update() starts an inline begin (transaction_id is None), it acquires self._lock while waiting for the transaction ID from the server. If that request failed with an error, the lock was never released. This was a latent bug in _async/transaction.py that became an active deadlock when async/sync parity was recently restored in snapshot.py: reintroducing _wait_for_transaction_begin() meant subsequent queries in the same transaction now try to acquire self._lock and hang. Wrap the request execution in try...finally in _async/transaction.py and regenerate sync transaction.py so self._lock is always released. Also: - Add unit tests for failed inline begin in both async and sync clients. - Add a GitHub Actions workflow to run Spanner mock server tests in CI. - Include the mockserver session in default local Nox runs.
olavloite
force-pushed
the
spanner-release-tx-lock-on-fail
branch
from
5769984 to
16d474c
Compare
September 17, 2026 12:02
sakthivelmanii
approved these changes
Sep 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When execute_update() or batch_update() starts an inline begin (transaction_id is None), it acquires self._lock while waiting for the transaction ID from the server. If that request failed with an error, the lock was never released.
This was a latent bug in _async/transaction.py that became an active deadlock when async/sync parity was recently restored in snapshot.py: reintroducing _wait_for_transaction_begin() meant subsequent queries in the same transaction now try to acquire self._lock and hang.
Wrap the request execution in try...finally in _async/transaction.py and regenerate sync transaction.py so self._lock is always released.
Also: