Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

fix: QueryJob.exception() *returns* the errors, not raises them#467

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
tswast merged 8 commits intogoogleapis:masterfromplamut:iss-451
Feb 25, 2021

Conversation

@plamut
Copy link
Contributor

Fixes#451.

This PR makes sure thatQueryJob.exception() actuallyreturns exceptions as documented, not raises them.

Checklist:

  • Make sure to open an issue as abug/issue 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)

@plamutplamut requested review froma team andtswastJanuary 12, 2021 12:26
@product-auto-labelproduct-auto-labelbot added the api: bigqueryIssues related to the googleapis/python-bigquery API. labelJan 12, 2021
@google-clagoogle-clabot added the cla: yesThis human has signed the Contributor License Agreement. labelJan 12, 2021
Copy link
Contributor

@tswasttswast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thanks!

Copy link
Contributor

@tswasttswast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Retracting approval until

Or can we call set_exception and return False in this case? We'd want a unit test that confirms result() doesn't get into an infinite loop.

is handled.

@plamutplamut added the do not mergeIndicates a pull request not ready for merge, due to either quality or timing. labelJan 27, 2021
@plamutplamut removed the do not mergeIndicates a pull request not ready for merge, due to either quality or timing. labelJan 27, 2021
@plamutplamut requested a review fromtswastJanuary 27, 2021 15:21
@plamut
Copy link
ContributorAuthor

plamut commentedJan 27, 2021•
edited
Loading

Hmm,TestQueryJob.test_result_w_retry seems to be flaky (failed run).

oogle.api_core.exceptions.RetryError: Deadline of 0.0s exceeded while calling functools.partial(functools.partial(<MagicMock name='mock.api_request' spec='function' id='140372364135632'>, method='GET', path='/projects/project/jobs/JOB_ID', query_params={}, timeout=None))

The same test passed with Python 3.6, 3.8, and also locally - let's see if the results are consistent on a re-run.

@plamutplamut added the kokoro:force-runAdd this label to force Kokoro to re-run the tests. labelJan 27, 2021
@yoshi-kokoroyoshi-kokoro removed the kokoro:force-runAdd this label to force Kokoro to re-run the tests. labelJan 27, 2021
@plamutplamut added the kokoro:force-runAdd this label to force Kokoro to re-run the tests. labelJan 27, 2021
@yoshi-kokoroyoshi-kokoro removed the kokoro:force-runAdd this label to force Kokoro to re-run the tests. labelJan 28, 2021
@plamut
Copy link
ContributorAuthor

I was able to reproduce flakiness on my machine by reducing the retry deadline in affected tests by ~25 %, which means the latter was indeed the culprit. Becausedone() now does a bit of extra work, it appears that was just enough of a slowdown to start causing the failures (at least under Python 3.7).

Although not ideal, increasing the deadline should be a solution sufficient with high enough probability.

is_done=job.done()

assertis_done
assertisinstance(job._exception,exceptions.BadRequest)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

why use the private property in this and the other tests? any objections to callingjob.exception() here and the other tests?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

The reasoning was thatjob.exception() can execute additional logic, and errors in that method would make the tests fordone() fail, too, even if there was nothing wrong with thedone() method itself.

One could argue that the chosen unit of test is too small, and that the class itself should represent a unit as opposed to its individual methods, but addressing that would require quite some refactoring (we already tinker with internal_properties , for instance).

Here, practicality beats purity IMHO, thus the "cheating" by examining the internal state of the class. Or do you have a strong opinion on this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Works for me. I agree that ideally we'd have higher-level tests than this, but makes sense to stay with existing conventions, especially given our 100% coverage requirement.

@plamutplamut requested a review fromtswastFebruary 23, 2021 13:44
is_done=job.done()

assertis_done
assertisinstance(job._exception,exceptions.BadRequest)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Works for me. I agree that ideally we'd have higher-level tests than this, but makes sense to stay with existing conventions, especially given our 100% coverage requirement.

@tswasttswast merged commitd763279 intogoogleapis:masterFeb 25, 2021
gcf-merge-on-greenbot pushed a commit that referenced this pull requestFeb 25, 2021
🤖 I have created a release \*beep\* \*boop\* ---## [2.10.0](https://www.github.com/googleapis/python-bigquery/compare/v2.9.0...v2.10.0) (2021-02-25)### Features* add BIGNUMERIC support ([#527](https://www.github.com/googleapis/python-bigquery/issues/527)) ([cc3394f](https://www.github.com/googleapis/python-bigquery/commit/cc3394f80934419eb00c2029bb81c92a696e7d88))### Bug Fixes* error using empty array of structs parameter ([#474](https://www.github.com/googleapis/python-bigquery/issues/474)) ([c1d15f4](https://www.github.com/googleapis/python-bigquery/commit/c1d15f4e5da4b7e10c00afffd59a5c7f3ded027a))* QueryJob.exception() *returns* the errors, not raises them ([#467](https://www.github.com/googleapis/python-bigquery/issues/467)) ([d763279](https://www.github.com/googleapis/python-bigquery/commit/d7632799769248b09a8558ba18f5025ebdd9675a))### Documentation* **bigquery:** Add alternative approach to setting credentials ([#517](https://www.github.com/googleapis/python-bigquery/issues/517)) ([60fbf28](https://www.github.com/googleapis/python-bigquery/commit/60fbf287b0d34d5db2e61cce7a5b42735ed43d0e))* explain retry behavior for DONE jobs ([#532](https://www.github.com/googleapis/python-bigquery/issues/532)) ([696c443](https://www.github.com/googleapis/python-bigquery/commit/696c443f0a6740be0767e12b706a7771bc1460c3))---This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
@plamutplamut deleted the iss-451 branchFebruary 25, 2021 19:45
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@tswasttswasttswast approved these changes

Assignees

No one assigned

Labels

api: bigqueryIssues related to the googleapis/python-bigquery API.cla: yesThis human has signed the Contributor License Agreement.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

google.cloud.bigquery.job.QueryJob.exception has wrong behavior

3 participants

@plamut@tswast@yoshi-kokoro
[8]ページ先頭
©2009-2025 Movatter.jp