feat: added client side metric instrumentation to read_rows and mutate_rows#16758
Conversation
…_2_instrumentation_advanced
daniel-sanche
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request integrates client-side metrics tracking into Bigtable data operations, including ReadRows and MutateRows, for both asynchronous and synchronous implementations. It introduces tracked_retry to capture operation metrics and refactors read_row to utilize operation classes directly, supported by extensive new system and unit tests. Feedback identifies opportunities to improve the efficiency of read_row by using next() or __anext__ on generators instead of converting them to lists, and suggests adding a type ignore comment in the synchronous code for consistency.
| raise close_exception | ||
| except Exception as generic_exception: | ||
| # handle exceptions in retry wrapper | ||
| raise generic_exception |
There was a problem hiding this comment.
Should we try extract the status code from Exception and call end_with_status in this block also? For example, if the stream timed out mid stream, will it be captured in the metrics?
There was a problem hiding this comment.
In this case, the exceptions are being captured by the tracked_retry object. I tried to cover the various tracking strategies here: go/bigtable-csm-python
| bt_exceptions.FailedMutationEntryError(idx, entry, cause_exc) | ||
| ) | ||
| if all_errors: | ||
| raise bt_exceptions.MutationsExceptionGroup( |
There was a problem hiding this comment.
will this affect extracting the grpc status code for the metric since we wrap it in a different exception?
There was a problem hiding this comment.
We have logic for converting exceptions to statuses is here. When we encounter an exception group, we use the last failure as the status
daniel-sanche
changed the title
daniel-sanche
added
the
kokoro:force-run
yoshi-kokoro
removed
the
kokoro:force-run
daniel-sanche
added
the
kokoro:force-run
yoshi-kokoro
removed
the
kokoro:force-run
🤖 I have created a release *beep* *boop* --- ## [2.39.0](google-cloud-bigtable-v2.38.0...google-cloud-bigtable-v2.39.0) (2026-06-22) ### Features * added client side metric instrumentation to read_rows and mutate_rows ([#16758](#16758)) ([4005e66](4005e66)) * **bigtable:** add client side metric instrumentation to basic rpcs ([#16712](#16712)) ([636af26](636af26)) * **bigtable:** add view_parameters support to execute_query ([#17382](#17382)) ([2695aad](2695aad)) * support row_range in sample_row_keys method ([#17330](#17330)) ([384724c](384724c)), closes [#17329](#17329) * update API sources and regenerate ([#17431](#17431)) ([2e75c78](2e75c78)) * update googleapis and regenerate ([33ba3af](33ba3af)) ### Bug Fixes * **bigtable:** ensure deadline is respected for read_rows_sharded ([#17352](#17352)) ([6cc890b](6cc890b)) * require Python 3.10+ ([#17245](#17245)) ([200b0d3](200b0d3)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
3 participants
Migration of googleapis/python-bigtable#1256 to the monorepo
Builds off of #16712 to add instrumentation to read_rows and mutate_rows, along with the mutation batcher