CuteChuanChuan commented on issue #2215: URL: https://github.com/apache/datafusion-comet/issues/2215#issuecomment-3239338942
Hi @andygrove and @kazuyukitanimura , After analyzing the error stack trace, I found that the error propagation flow inside CometExecIterator.getNextBatch follows this path: nativeLib.executePlan → catch block → throw error Based on this analysis, I propose the following approach to address issue #2215: 1. Create a private method to retrieve the current SQL text: I'm currently investigating whether we can use SQLExecution.EXECUTION_ID_KEY to fetch the actual SQL query text. However, I'm still exploring the best way to access the original SQL statement at this execution stage. 2. Create a helper method to format error messages with SQL context: This would format the error message to match Spark's native error format, including the == SQL == section. 3. Enhance the exception handling in CometExecIterator (line 169): Add additional case branches to check if the CometNativeException contains Spark error codes (e.g., CAST_INVALID_INPUT). When detected, apply the SQL context formatting from step 2 before re-throwing the exception. Does this approach seem reasonable and feasible? I would greatly appreciate your guidance and feedback on this proposed solution, particularly regarding: - The feasibility of accessing SQL text at the execution phase - Any potential issues or better alternatives you might suggest Thank you for your time and guidance! -- 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]
