rangareddy commented on issue #17374:
URL: https://github.com/apache/hudi/issues/17374#issuecomment-5351240344
This issue was reviewed as part of the JIRA-migrated backlog triage
(HUDI-9095).
**Findings: confirmed, unchanged in substance on `master`.**
The scary output comes from one line,
`hudi-common/src/main/java/org/apache/hudi/common/util/RetryHelper.java:105`:
```java
log.warn("Task [{}] failed. current retry number {}, will retry after {}
ms.", taskInfo, retries, waitTime, e);
```
The trailing `e` is the point - SLF4J treats a trailing throwable as the
exception to render, so every transient retry prints a full stack trace at
WARN. In the case you captured (routine file-creation retries in the metadata
table's `column_stats` partition) the operation goes on to succeed, so a user
reading the log sees repeated stack traces for something that did not actually
fail.
The message text has been reworded since you filed this - it now carries the
task info and retry number - but the throwable is still logged at WARN on every
attempt, so the reported experience is unchanged.
A low-risk fix that keeps the diagnostics: log `e.getMessage()` at WARN on
intermediate attempts and the full trace at DEBUG, and only emit the complete
stack trace at WARN or ERROR when the final attempt fails. That keeps the
signal for genuine failures without making a healthy retry look like a crash.
Keeping this open.
--
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]
