fix(bigquery/storage/managedwriter): correct reconnection logic #8164
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.
Signalling for an AppendRows stream when schema changes is predicated on the backend's status for the connection. For a simplex (non-multiplexed) connection, the expectation is the client closes and reconnects to signal there's a change in the schema.
For a connection in multiplex mode, no reconnection is necessary and the backend will look at the schema for changes.
In managedwriter, we allow a user to specify multiplex at the outset, but for connections that haven't actually sent writes for more than a single stream ID the backend doesn't recognize the multiplex status. Essentially, client state is out of sync with server state until a second stream writes on the same connection.
This PR expands the interface for send optimizer to signal whether the optimizer has sent writes for multiple connections, and uses it when making the determination about schema-based reconnects. It also augments the schema evolution test to validate using multiple combinations of writer and client options.