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.
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(redshift): Improve redshift error handling with new structured reporting system #10870
refactor(redshift): Improve redshift error handling with new structured reporting system #10870
Changes from 4 commits
fcd31c3
118b337
31f5788
116d315
3aae262
2655152
c8819dd
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a huge fan of this pattern - ideally error handling code should be close to the code that causes the errors, especially for these sorts of cases where the error message is extremely custom
For the generic permission denied / failed to extract metadata, they're fine here. But the svv and svl table ones feel like they should be caught closer to the cause of the error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These happen in like 3 places across lineage, usage, and just normal table stuff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also the code is a mess in there so I think this fallback is okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I agree though that this is too much of a fallback, but in this case it would be a pretty significant undertaking to cover each place we are issuing queries via the client object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(And this covered the cases I tested with a new sample user who I progressively added privileges for)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can also see I'm just catching the "redshift" connector errors here as of now, also. So it's fairly targeted to mean that the exception came from a redshift connector call.