DDtKey opened a new issue, #4981:
URL: https://github.com/apache/arrow-datafusion/issues/4981

   **Describe the bug**
   [This line of 
code](https://github.com/apache/arrow-datafusion/blob/master/datafusion/core/src/physical_plan/joins/utils.rs#L695)
 makes impossible to get real reason of error.
   ```rs
   .map_err(|e| ArrowError::ExternalError(e.to_string().into())),
   ```
   
   It could produce such error: `External error: Arrow error: External error: 
Arrow error: External error: Arrow error: External error: Arrow error: Csv 
error: ...`
   
   That's actually really bad, because under `Csv error` it could be useful 
info. But instead of this I receive text error with too many nested `External` 
variants.
   
   **To Reproduce**
   Occurrence depends on execution plan and my data that caused this is rather 
large.
   I believe it should be possible to cover with simple test of error type:
   ```rs
   #[tokio::test]
       async fn check_error_nesting() {
           let once_fut = OnceFut::<()>::new(async {
               Err(DataFusionError::ArrowError(ArrowError::CsvError("some 
error".to_string())))
           });
   
           struct TestFut(OnceFut<()>);
           impl Future for TestFut {
               type Output = ArrowResult<()>;
   
               fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> 
Poll<Self::Output> {
                   match ready!((&mut self.0).get(cx)) {
                       Ok(()) => Poll::Ready(Ok(())),
                       Err(e) => Poll::Ready(Err(e)),
                   }
               }
           }
   
           let res = TestFut(once_fut).await;
           let err = res.expect_err("future always return err");
           // ... some checks of error type
   
       }
   ```
   
   
   **Expected behavior**
   I expect to be able to take error type instead of message in string format.
   However, I see that it's reference and need to figure out right way to 
handle this case. But current one breaks error handling system for datafustion.
   
   **Additional context**
   I would like to help/fix this behavior, however need to discuss right 
approach
   


-- 
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]

Reply via email to