hudi-agent commented on code in PR #18611:
URL: https://github.com/apache/hudi/pull/18611#discussion_r3532511104
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/metadata/HoodieBackedTableMetadataWriter.java:
##########
@@ -1076,7 +1076,9 @@ private List<DirectoryInfo>
listAllPartitionsFromFilesystem(String initializatio
final int fileListingParallelism =
metadataWriteConfig.getFileListingParallelism();
StorageConfiguration<?> storageConf = dataMetaClient.getStorageConf();
final String dirFilterRegex =
dataWriteConfig.getMetadataConfig().getDirectoryFilterRegex();
+ final boolean skipZeroSizeFiles =
dataWriteConfig.getMetadataConfig().shouldSkipZeroSizeFilesOnInitialize();
Review Comment:
🤖 The rename cleanly addresses the naming feedback. It doesn't change one
thing from the last round though: this helper is still called from the
restore-sync path (line 1744, `update(HoodieRestoreMetadata, ...)`), so both
the filtering and the new `skipped_zero_size_files_on_initialize` metric now
fire during restore — which isn't an initialize. In that path any MDT-tracked
file absent from the now zero-size-filtered FS listing is scheduled for
deletion (lines 2320-2321), so a zero-size file already tracked in MDT would
get a spurious delete record while still on disk. Since the PR is framed as
bootstrap-only, would passing `skipZeroSizeFiles` as a parameter (restore
passes `false`) keep it scoped as intended?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
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]
