RohanExploit opened a new pull request, #11823: URL: https://github.com/apache/seatunnel/pull/11823
### Purpose of this pull request Closes the diagnosability gap in #10172. On a Kerberos-enabled HDFS connection, `FileSystem.get()` builds a `DFSClient` that reaches into Hadoop internals (e.g. `FsTracer`) whose signatures have changed across Hadoop releases. When the Hadoop client jars resolved at runtime — a `provided` dependency supplied by the deployment environment, not bundled here — don't match what SeaTunnel was built against, the failure surfaces as a raw `NoSuchMethodError`/`NoClassDefFoundError` deep inside Hadoop's own code, with nothing pointing at the real cause. This wraps that call and rethrows an `IOException` naming the likely cause and the version this connector targets (Hadoop 3.1.4, per `seatunnel-hadoop3-3.1.4-uber`). The working path is untouched — this is diagnostic only, not a behavior change. ### Does this PR introduce _any_ user-facing change? No change on success. On this specific failure the user sees a clear `IOException` explaining the likely version mismatch instead of a bare JVM linkage error. ### How was this patch tested? Two unit tests in `HadoopFileSystemProxyTest`: one simulates a `NoSuchMethodError` and asserts it is rewritten to the diagnostic `IOException` with the original preserved as the cause (fails before this change, passes after); one asserts the success path passes through unchanged. --- Disclosure: this change was AI-assisted (Claude). I reviewed it and can speak to the reasoning. -- 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]
