Open
Labels
api: spannerIssues related to the Spanner API.Issues related to the Spanner API.priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Description
Determine this is the right repository
- I determined this is the correct repository in which to report this bug.
Summary of the issue
Context
When the Spanner is unavailable. If we call run_in_transaction, the Spanner client will stuck forever.
We believe the get_session should in the try catch block. Otherwise, the self._local.transaction_running = True will be forever True.
Expected Behavior:
The client will retry when the Spanner DB is back.
Actual Behavior:
The client stuck forever.
API client name and version
No response
Reproduction steps: code
No response
Reproduction steps: supporting files
- Try to create a session when Spanner is unavailable.
- The client will be stuck forever.
Reproduction steps: actual results
No response
Reproduction steps: expected results
No response
OS & version + platform
No response
Python environment
No response
Python dependencies
No response
Additional context
No response
Metadata
Metadata
Assignees
Labels
api: spannerIssues related to the Spanner API.Issues related to the Spanner API.priority: p2Moderately-important priority. Fix may not be included in next release.Moderately-important priority. Fix may not be included in next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Activity
mukeshr06 commentedon Sep 19, 2026
I reproduced this on current main: after get_session() raises ServiceUnavailable, the next run_in_transaction() call on the same thread raises the nested-transaction RuntimeError before session acquisition is attempted. I am preparing a focused fix that includes session acquisition in the existing cleanup scope and only returns a session to the pool if acquisition succeeded. The regression test fails before the fix and checks that a later call can succeed. This contribution is being prepared with AI assistance.