hjk612 opened a new pull request, #8289:
URL: https://github.com/apache/gravitino/pull/8289
Remove redundant operation parameter from LOG.warn call in
runWithExceptionTranslation method. The message is already formatted with the
operation using String.format(), so passing the operation parameter again to
LOG.warn is incorrect and redundant.
This change makes the logging consistent with other catch blocks in the same
method.
**Title:** `[#8285] fix(filesystem): remove redundant operation parameter in
LOG.warn call`
### What changes were proposed in this pull request?
This PR fixes a redundant parameter issue in the `LOG.warn` call within the
`runWithExceptionTranslation` method of `GravitinoVirtualFileSystem.java`.
**Change made:**
- Removed the redundant `operation` parameter from `LOG.warn(message,
operation, e)`
- Changed it to `LOG.warn(message, e)` to match the correct SLF4J logging
pattern
### Why are the changes needed?
The current code incorrectly passes the `operation` parameter twice to the
LOG.warn call:
1. Once in the formatted message via `String.format("Cannot get fileset
catalog during %s", operation)`
2. Again as a separate parameter: `LOG.warn(message, operation, e)`
This is incorrect SLF4J usage and creates inconsistency within the same
method, as the other two catch blocks correctly use `LOG.warn(message, e)`.
Fix: #8285
### Does this PR introduce _any_ user-facing change?
No, this PR does not introduce any user-facing changes. This is purely an
internal logging fix with no impact on APIs, functionality, or user-visible
behavior.
### How was this patch tested?
- **No new tests needed:** This is a logging fix that doesn't change
functional behavior, so no additional tests are required
- **Consistency check:** Verified that all three catch blocks in
`runWithExceptionTranslation` now follow the same logging pattern:
`LOG.warn(message, e)`
--
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]
