fix: fix Scanner file handle leak in HiveIncrementalPuller.executeIncrementalSQL#18457
Conversation
…ecuteIncrementalSQL
yihua
left a comment
There was a problem hiding this comment.
🤖 This review was generated by an AI agent and may contain mistakes. Please verify any suggestions before applying.
LGTM — clean, minimal fix that correctly addresses the file handle leak using try-with-resources. The Scanner is now guaranteed to close on both normal exit and exception paths, with no change to observable behavior.
|
Pinging for committer approval. This PR fixes a |
CI Build Failures — Master Branch Issue (not this PR)The Evidence:
The CI situation is being tracked. Once the master build stabilises, a re-run of CI on this PR should pass. cc @vinothchandrasekar @alexeykudinkin @danny0405 @nsivabalan — would appreciate a re-run once the master build issue is resolved. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #18457 +/- ##
============================================
+ Coverage 66.50% 68.85% +2.34%
- Complexity 22910 28222 +5312
============================================
Files 2004 2460 +456
Lines 112236 135260 +23024
Branches 14250 16395 +2145
============================================
+ Hits 74645 93129 +18484
- Misses 31087 34758 +3671
- Partials 6504 7373 +869
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Describe the issue this Pull Request addresses
In
HiveIncrementalPuller.executeIncrementalSQL(), ajava.util.Scannerused to read the incremental SQL file is never explicitly closed. On every invocation this leaks a file descriptor, which can exhaust OS file descriptor limits in long-running jobs.Summary and Changelog
Fixed a
Scannerresource leak inHiveIncrementalPuller.executeIncrementalSQL()by wrapping theScannerin a try-with-resources block so it is always closed after use.HiveIncrementalPuller.java: Converted plainnew Scanner(...)to a try-with-resources statement, ensuring theScanneris closed regardless of whether an exception is thrown during file reading.Impact
No public API or user-facing change. Prevents file descriptor exhaustion in long-running incremental pull pipelines.
Risk Level
low — Only affects resource cleanup; no functional query or SQL parsing logic changed.
Documentation Update
none
Contributor's checklist