Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 5 commits
- 6 files changed
- 2 contributors
Commits on Nov 18, 2022
-
fix: Prevent sending full table scan when retrying (backport #554) (#697
) Update the retry logic. Don't send empty row_key and empty row_ranges if the original message didn't ask for those. Closes internal issue 214449800 * Create InvalidRetryRequest exception. Raise InvalidRetryRequest instead of StopIteration Catch the InvalidRetryRequest Handle stop the retry request if row_limit has been reached.
-
fix: make sure that the proper exception type is bubbled up for ReadR…
…ows (#696) ReadRows (in client 1.x) bypasses gapic layer and use the raw grpc stubs. Which means that the errors are not being wrapped. Previously the this conversion would be handled in the Retry predicate, however this creates usability issues for end users that are trying to change the exceptions they want to retry on. This PR moves the wrapping a bit lower Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly: - [ ] Make sure to open an issue as a [bug/issue](https://togithub.com/googleapis/python-bigtable/issues/new/choose) before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea - [ ] Ensure the tests and linter pass - [ ] Code coverage does not decrease (if any source code was changed) - [ ] Appropriate docs were updated (if necessary) Fixes #<issue_number_goes_here> 🦕
-
fix: first pass on making retry configuration more consistent (#695)
* fix: first pass on making retry configuration more consistent Currently ReadRows uses the Retry.deadline configuration inconsistently: - its used as the attempt timeout for the first retry attempt - its used as a limit for retry scheduling for reading a single row Conceptually there are 3 timeouts that are relevant to ReadRows: - attempt timeout: how long a single RPC is allowed to run, this should map directly to a gRPC deadline - overall timeout: Limit how long we should wait across all of the retry attempts, possibly truncating the last attempt timeout. - read timeout: How long we are willing to wait for the next row in a stream Ideally Retry.deadline would represent an operation deadline (since thats the primary concern of the end user). However there is no backwards compatible way to do this. Changing the behavior would cause existing application to start enforcing a very short deadline. This PR tries to improve the situation in a backwards compatible way: - keep Retry.deadline as a read timeout - introduce a new parameter for overall timeout This results in less than ideal api, but avoids breaking existing applications. * fix old test * add attempt timeout * lint * add some tests * lint * refactor confusing logic * apply fixes from review * address feedback
-
fix: make internal rst_stream errors retriable (#699)
* fix: make internal rst_stream errors retriable * catch more rst stream variants
-
chore(v1): release 1.7.3 (#698)
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v1.7.2...v1.7.3