nchammas commented on PR #57831: URL: https://github.com/apache/spark/pull/57831#issuecomment-5254463017
> I think the community does not currently seem to treat all error condition names as part of the public API contract, nor does it subject them to sufficiently rigorous review, but I agree we should be careful about those error conditions already used by older versions of the client for control flow. Yes, over time it will become more important to stabilize these error conditions as more clients come to depend on them. > Specific to the error conditions in this PR, @nchammas, do you have a concrete suggestion for how we should handle them? Since [SPARK-57933](https://issues.apache.org/jira/browse/SPARK-57933) is included in 4.3, I don't want to defer this one to the next version and accumulate the tech debt. My guidance would be: 1. @j1wonpark's proposed split between `INVALID_HANDLE` (class `HY`) and `SESSION_UNAVAILABLE` (class `08`) sounds good to me. 2. We should include a migration guide note about any error conditions we change, because they are technically part of the public interface. 3. I think we can make do with just splitting the conditions into different groups and avoid allowing sub-conditions to override the parent condition error state. That would be simplest. I prefer this solution. 4. If down the line we _really_ want sub-conditions to be able to declare a different error state than their parents, then we must have code that enforces that the error class cannot be different. (It would probably be a test [like this one][1].) But I think we don't need this for the current use case. [1]: https://github.com/apache/spark/blob/b3c0402a9c8da97c655a52c791cc59d6f8ea9789/core/src/test/scala/org/apache/spark/SparkThrowableSuite.scala#L117 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
