danny0405 commented on code in PR #18816:
URL: https://github.com/apache/hudi/pull/18816#discussion_r3892404305
##########
hudi-cli/src/main/java/org/apache/hudi/cli/commands/RepairsCommand.java:
##########
@@ -201,7 +201,9 @@ public void removeCorruptedPendingCleanAction() {
TimelineUtils.deleteInstantFile(client.getStorage(),
client.getTimelinePath(),
instant, client.getInstantFileNameGenerator());
} catch (IOException ioe) {
- if (ioe.getMessage().contains("Not an Avro data file")) {
+ if (ioe.getMessage() == null || ioe.getMessage().contains("Not an Avro
data file")
Review Comment:
[P1] The narrowed condition still deletes valid clean plans on transient
read failures.
This remains reproducible at `059d0af2`: both
`CommitMetadataSerDeV1.deserialize` and `CommitMetadataSerDeV2.deserialize`
catch arbitrary exceptions and wrap them in `IOException("[Uu]nable to read
commit metadata ...")`. That message does not establish that the file is empty
or corrupt.
I serialized a valid `HoodieCleanerPlan`, verified that it deserializes
successfully, then injected a `SocketTimeoutException` after reading its first
32 bytes. Both serdes produced the matched wrapper with the timeout as its
cause. Running the PR's `removeCorruptedPendingCleanAction()` against that
stream invoked `storage.deleteFile()` for the requested clean instant (verified
with mocked storage). Restoring the previous IOException condition propagated
the failure without deleting the file.
Could we distinguish verified empty/corrupt content from storage read
failures before deleting, and propagate transient I/O errors? Please add a
regression test asserting that a read timeout on a valid pending clean plan
does not delete its instant file. Otherwise a temporary storage outage can
permanently remove a healthy pending clean plan. Harness validation used the
PR's command and serde sources against the locally cached dependencies; I did
not run the full CLI suite.
--
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]
