[
https://issues.apache.org/jira/browse/SPARK-58619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiwon Park updated SPARK-58619:
-------------------------------
Component/s: Connect
(was: Spark Core)
Affects Version/s: 4.3.0
(was: 5.0.0)
Description:
{{INVALID_HANDLE}} (SQLSTATE {{HY000}}, class {{HY}} = CLI-specific condition)
currently groups two unrelated families of sub-conditions:
* {{FORMAT}}, {{OPERATION_ABANDONED}}, {{OPERATION_ALREADY_EXISTS}},
{{OPERATION_NOT_FOUND}} - a malformed or misused handle on a healthy session,
which {{HY000}} describes adequately.
* {{SESSION_CHANGED}}, {{SESSION_CLOSED}}, {{SESSION_NOT_FOUND}} - the
server-side session backing a Connect client is gone, which SQL standard
{{08003}} (connection does not exist) describes. These inherited {{HY000}}
accidentally: {{INVALID_HANDLE}} received it when it only covered
handle-validity errors (SPARK-44422), and the session sub-conditions were
folded in later.
Consequences: tools that detect dead connections by SQLSTATE class {{08}}
cannot recognize these errors, so the Connect JDBC driver hard-codes a
{{SESSION_*}} -> {{08003}} remapping (raised in the SPARK-57933 review); and
since {{getMessageTemplate}} concatenates the parent and sub-condition
messages, {{SESSION_CHANGED}} renders as "The handle xxx is invalid. The
existing Spark server driver instance has restarted." although the handle is
valid.
Per the review consensus on the original PR (sub-condition level SQLSTATE
override was rejected in favor of restructuring), move the three session
sub-conditions to a new top-level condition {{SESSION_UNAVAILABLE}} with
SQLSTATE {{08003}}, sub-conditions {{CHANGED}} / {{CLOSED}} / {{NOT_FOUND}},
and the message "The session <handle> is no longer available.";
{{INVALID_HANDLE}} keeps {{FORMAT}} and the {{OPERATION_*}} sub-conditions with
{{HY000}}. Released Connect clients match the old condition names to drive
session invalidation and transparent reattach, so the reattach matchers accept
both the old and new names, and the rename is noted in the migration guide.
was:
A SQLSTATE can only be assigned to a top-level error condition:
{{ErrorSubInfo}} has no {{sqlState}} field and
{{ErrorClassesJsonReader.getSqlState}} resolves only the main condition, so
every sub-condition unconditionally inherits its parent's value.
{{INVALID_HANDLE.SESSION_CHANGED}}, {{SESSION_CLOSED}}, and
{{SESSION_NOT_FOUND}} mean the server-side session backing a Connect client is
gone, which SQL standard 08003 (connection does not exist) describes, yet they
inherit the generic HY000 that {{INVALID_HANDLE}} received before they were
added. The Connect JDBC driver hard-codes a remapping as a result (raised in
the SPARK-57933 PR review), and splitting them into new top-level conditions
would break deployed clients that match the condition names to drive
transparent reattach and session invalidation.
Proposal: add an optional {{sqlState}} field to {{ErrorSubInfo}} and resolve
the sub-condition's SQLSTATE first with fallback to the main condition's (as
{{getBreakingChangeInfo}} already does), assign 08003 to the three session
sub-conditions, and give PySpark's {{get_sqlstate}} the same fallback (it
currently reports no SQLSTATE for sub-conditions without their own, e.g.
{{NEAREST_BY_JOIN.UNSUPPORTED_MODE}}).
Summary: Split the INVALID_HANDLE session sub-conditions into a
new SESSION_UNAVAILABLE error condition with SQLSTATE 08003 (was: Support
sub-condition level SQLSTATE in the error condition framework)
> Split the INVALID_HANDLE session sub-conditions into a new
> SESSION_UNAVAILABLE error condition with SQLSTATE 08003
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SPARK-58619
> URL: https://issues.apache.org/jira/browse/SPARK-58619
> Project: Spark
> Issue Type: Improvement
> Components: Connect
> Affects Versions: 4.3.0
> Reporter: Jiwon Park
> Priority: Major
> Labels: pull-request-available
>
> {{INVALID_HANDLE}} (SQLSTATE {{HY000}}, class {{HY}} = CLI-specific
> condition) currently groups two unrelated families of sub-conditions:
> * {{FORMAT}}, {{OPERATION_ABANDONED}}, {{OPERATION_ALREADY_EXISTS}},
> {{OPERATION_NOT_FOUND}} - a malformed or misused handle on a healthy session,
> which {{HY000}} describes adequately.
> * {{SESSION_CHANGED}}, {{SESSION_CLOSED}}, {{SESSION_NOT_FOUND}} - the
> server-side session backing a Connect client is gone, which SQL standard
> {{08003}} (connection does not exist) describes. These inherited {{HY000}}
> accidentally: {{INVALID_HANDLE}} received it when it only covered
> handle-validity errors (SPARK-44422), and the session sub-conditions were
> folded in later.
> Consequences: tools that detect dead connections by SQLSTATE class {{08}}
> cannot recognize these errors, so the Connect JDBC driver hard-codes a
> {{SESSION_*}} -> {{08003}} remapping (raised in the SPARK-57933 review); and
> since {{getMessageTemplate}} concatenates the parent and sub-condition
> messages, {{SESSION_CHANGED}} renders as "The handle xxx is invalid. The
> existing Spark server driver instance has restarted." although the handle is
> valid.
> Per the review consensus on the original PR (sub-condition level SQLSTATE
> override was rejected in favor of restructuring), move the three session
> sub-conditions to a new top-level condition {{SESSION_UNAVAILABLE}} with
> SQLSTATE {{08003}}, sub-conditions {{CHANGED}} / {{CLOSED}} / {{NOT_FOUND}},
> and the message "The session <handle> is no longer available.";
> {{INVALID_HANDLE}} keeps {{FORMAT}} and the {{OPERATION_*}} sub-conditions
> with {{HY000}}. Released Connect clients match the old condition names to
> drive session invalidation and transparent reattach, so the reattach matchers
> accept both the old and new names, and the rename is noted in the migration
> guide.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
