[SPARK-45808][CONNECT][PYTHON] Better error handling for SQL Exceptions #43667
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HyukjinKwon
approved these changes
Nov 6, 2023
Member
HyukjinKwon
left a comment
HyukjinKwon
left a comment
There was a problem hiding this comment.
amazing, LGTM
@itholic mind double checking?
Member
|
Oh let's also file a JIRA btw |
grundprinzip
changed the title
Contributor
Author
|
Filed SPARK-45808 |
HyukjinKwon
reviewed
Nov 6, 2023
| ErrorUtils.throwableToFetchErrorDetailsResponse( | ||
| st = error, | ||
| serverStackTraceEnabled = sessionHolder.session.conf.get( | ||
| Connect.CONNECT_SERVER_STACKTRACE_ENABLED) || sessionHolder.session.conf.get( |
Contributor
There was a problem hiding this comment.
Are we deprecating this config Connect.CONNECT_SERVER_STACKTRACE_ENABLED?
Contributor
Author
There was a problem hiding this comment.
It's still used, but only verifies the display behavior rather than the stack trace generation.
Contributor
There was a problem hiding this comment.
Should we also make Connect.CONNECT_SERVER_STACKTRACE_ENABLED work for Scala client in this pr?
Contributor
Author
There was a problem hiding this comment.
This is a bit more weird, in contrast to Python, the server backtrace is always there in Scala, but the user can decide how to print it.
Member
|
Merged to master. |
Contributor
|
Late LGTM. This is cool. Thanks! |
HyukjinKwon
pushed a commit
that referenced
this pull request
Dec 19, 2023
### What changes were proposed in this pull request? Revert #44144, and introduce a forbid recursion guard as previously proposed. This way the infinite error handling recursion is still prevented, but the client-side knob is still present. ### Why are the changes needed? Previously proposed as part of #44144, however was discussed in favour of something else. However it seems (proposal by grundprinzip) that the original proposal was more correct, since it seems driver stacktrace is decided on client not server (see #43667) ### Does this PR introduce _any_ user-facing change? No ### How was this patch tested? Hand testing ### Was this patch authored or co-authored using generative AI tooling? No Closes #44210 from cdkrot/forbid_recursive_error_handling_2. Authored-by: Alice Sayutina <[email protected]> Signed-off-by: Hyukjin Kwon <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
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.
What changes were proposed in this pull request?
This patch optimizes the handling of errors reported back to Python. First, it properly allows the extraction of the
ERROR_CLASSand theSQL_STATEand gives simpler accces to the stack trace.It therefore makes sure that the display of the stack trace is no longer only server-side decided but becomes a local usability property.
In addition the following methods on the
SparkConnectGrpcExceptionbecome actually useful:getSqlState()getErrorClass()getStackTrace()Why are the changes needed?
Compatibility
Does this PR introduce any user-facing change?
No
How was this patch tested?
Updated the existing tests.
Was this patch authored or co-authored using generative AI tooling?
No