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
For ReadRows request, when we received a retryable exception at the end of the stream after consuming all the rows, the client will initiate a new attempt RPC which has a fake ReadRowsRequest. This is fine in the most cases because the request is not actually getting send to the server and the returned response is correct.
However, when client side metrics is enabled, this would show up as an extra client RPC with cluster_id=unspecified, zone_id=global, table_id=undefined, and status=OK: https://screenshot.googleplex.com/B6HqQdHMJduK5XP. The cluster_id and zone_id are unspecified because no request is send to server so nothing is returned, the table_id is undefined because we skipped setting table name in the fake FULFILLED_REQUEST_MARKER request.
This could be confusing because usually when cluster_id is unspecified it means the request failed before it reaches Bigtable server, in which case the status would be OK. And table_id should never be undefined because we get the table_id from the request.
The text was updated successfully, but these errors were encountered:
For ReadRows request, when we received a retryable exception at the end of the stream after consuming all the rows, the client will initiate a new attempt RPC which has a fake ReadRowsRequest. This is fine in the most cases because the request is not actually getting send to the server and the returned response is correct.
However, when client side metrics is enabled, this would show up as an extra client RPC with
cluster_id=unspecified
,zone_id=global
,table_id=undefined
, andstatus=OK
: https://screenshot.googleplex.com/B6HqQdHMJduK5XP. The cluster_id and zone_id are unspecified because no request is send to server so nothing is returned, the table_id is undefined because we skipped setting table name in the fake FULFILLED_REQUEST_MARKER request.This could be confusing because usually when cluster_id is unspecified it means the request failed before it reaches Bigtable server, in which case the status would be OK. And table_id should never be undefined because we get the table_id from the request.
The text was updated successfully, but these errors were encountered: