Suppress the bigquery job sql in exception messages (#2383) #2393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
resolves #2383
Description
The bigquery library appends the job sql to the exception message, but we don't want that.
There are a couple other paths this could go down instead, I'm not sure which is the most future-proof:
exception.args[0]
, which will have the original message it gotexception.errors
, which will be a list of dicts. Each member of the list (apparently) will have amessage
key that is the original message.The other options depend upon google not changing internal workings of their libraries, this option depends on google not changing their error messages. Hard to say what's better, but I kind of assume the output is more reliable than internals!
I figure if the "string contains" check fails it will fail in an annoying-but-not-critical way, as opposed to AttributeErrors in exception handlers.
Checklist
CHANGELOG.md
and added information about my change to the "dbt next" section.