[I] So we basically have a 2nd file parser here 🤔 I'm wondering if instead of creating yet-another-parser -- even though it's partial -- we could ask the decoder to provide us a "reason" or a "trace" on the individual read requests. For example, we could extend `AsyncFileReader` with an implemented-by-default method: [arrow-rs]

[via GitHub]

alamb opened a new issue, #8157:
URL: https://github.com/apache/arrow-rs/issues/8157

   So we basically have a 2nd file parser here 🤔 I'm wondering if instead of 
creating yet-another-parser -- even though it's partial -- we could ask the 
decoder to provide us a "reason" or a "trace" on the individual read requests. 
For example, we could extend `AsyncFileReader` with an implemented-by-default 
method:
   
   ```rust
   trait AsyncFileReader {
      // all the current methods stay!
   
      fn get_bytes_with_trace(&mut self, range: Range<u64>, trace: Trace) -> 
BoxFuture<'_, parquet::errors::Result<Bytes>> {
           // ignore trace by default
           self.get_bytes(range)
      }
   
      // same for the other two methods...
   }
   
   // bikeshed whatever `Trace` is, maybe use :http::Extensions?
   ```
   
   _Originally posted by @crepererum in 
https://github.com/apache/arrow-rs/pull/7971#discussion_r2262364717_
               


-- 
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: github-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org