You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
spanner: do not fall back to explicit BeginTransaction on exhausted transient stream errors #7173
When a multi-use read-only or read-write transaction executes its first statement with inlined begin (InlineBegin), transient errors (e.g. Unavailable) on stream creation or resumption are retried according to the configured retry and backoff policies.
However, once those retries are completely exhausted, handle_stream_initialization_error currently returns false (for multi-use read-only transactions), which causes the client to fall back to an explicit BeginTransaction RPC and retry the statement again.
If retries have already been exhausted due to transient connectivity or availability issues, falling back to an explicit BeginTransaction RPC and re-attempting the query is usually undesirable because:
It indicates a genuine network or backend outage, so BeginTransaction will also fail or consume another full round of retries and timeouts.
Fallback to BeginTransaction was originally intended for cases where the initial inlined begin could not start the transaction due to semantic statement errors (e.g. table not found or statement syntax errors) while preserving the transaction snapshot for subsequent statements, rather than continuing to retry after a transient connection error has exhausted its retry budget.
Expected Behavior
When an inlined begin stream fails due to transient errors that exhaust the configured retry policy, the error should be returned directly to the caller without falling back to an explicit BeginTransaction RPC.
Activity