feat: surface retry param to Table.read_row api

[ayubun]

what ? (￣^￣ゞ

this pr surfaces a retry param for Table.read_row. this param defaults to DEFAULT_RETRY_READ_ROWS just as it does for Table.read_rows. it then passes forward into the Table.read_rows call

why ? („• ᴗ •„)

in the case where a caller may want to override the default retry param for the Table.read_row api, they currently must switch to using Table.read_rows and add their own code for pulling the first item out of the iterator and guarding against multi-row responses (which are functionalities that Table.read_row already provides)

in an ideal world, the Table.read_row helper method can accept and pass along the retry param so that clients don't need to write their own duplicate implementations wrapping Table.read_rows~

related issue ౨ৎ⋆˚｡⋆

implements #941

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

[ayubun]

i wanted to bump this since it's been a while ^^; @rkaregar

[daniel-sanche]

There seems to be an issue in the owlbot test, unreleated to these changes. I'll merge this when that is resolved

[daniel-sanche]

Actually, it looks like it's failing on the noxfile customizations. These were stripped out in the upstream main owlbot.py file. So I think the issue is because the tests are running against your branch, which doesn't contain all the upstream changes.

Please merge in upstream's main, and then we should be good to go

[ayubun]

@daniel-sanche done

[daniel-sanche]

thanks! There's now a CI issue on the backend, but I will merge this when that is resolved

[mwarkentin]

@ayubun @daniel-sanche #941 mentioned both retries and timeouts - I'm not sure but it looks like this adds retry but not timeout config? Or are they combined somehow in the retry param?

[mwarkentin]

Ah, I see: https://github.com/ayubun/python-bigtable/blob/c8c04d35b6e236fe98d350ca45dc49fc059da8cb/google/cloud/bigtable/row_data.py#L96

[mwarkentin]

Does this look like the right way to override the timeout (based on this doc)?

from google.cloud.bigtable.row_data import DEFAULT_RETRY_READ_ROWS modified_retry = DEFAULT_RETRY.with_deadline(5.0) row = self._get_table().read_row(key, retry=modified_retry)

[daniel-sanche]

@mwarkentin Yeah, that code you supplied looks right. Technically you should be using .with_timeout (explaination here), but deadline is still supported as an equivalent alias

This uses the api_core.Retry class, which is shared across all GCP python libraries for retry/timeout/backoff configuration. You can find more documentation here

[mwarkentin]

Thanks!

[mwarkentin]

@daniel-sanche if with_timeout is preferred, probably good to update the docs here which only suggest using with_deadline: https://cloud.google.com/python/docs/reference/storage/latest/retry_timeout#configuring-retries

[daniel-sanche]

Thanks, I opened a request to have that fixed!