Fix HoodieStorage resource leak in FileSystemBasedLockProvider.close()

[mailtoboggavarapu-coder]

Problem

FileSystemBasedLockProvider creates a HoodieStorage instance in its constructor but never closes it in the close() method. Since HoodieStorage implements Closeable and holds underlying filesystem connections, this causes a resource leak every time the lock provider is closed.

Solution

Add a finally block inside close() to ensure storage.close() is always called after the lock file deletion attempt, regardless of whether deletion succeeds or throws an exception. IOException from storage.close() is caught and logged as a warning to avoid masking the original exception.

Changes

• FileSystemBasedLockProvider.java: Added finally block in close() to call storage.close() with proper exception handling.

[hudi-bot]

CI report:

• 369d907 Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build

[mailtoboggavarapu-coder]

Pinging for an initial review. This PR fixes a genuine resource leak: FileSystemBasedLockProvider creates a HoodieStorage (which holds underlying filesystem connections and implements Closeable) in its constructor but never closes it in close(). The fix is a one-liner — calling storage.close() inside the existing close() method so the resource is released every time the lock provider is torn down.

Would appreciate a review from a committer with write access to apache/hudi (@vinothchandrasekar / @alexeykudinkin / @danny0405 / @nsivabalan).

[danny0405]

good catch, can you fix the indentation.