void-ptr974 opened a new issue, #4804: URL: https://github.com/apache/bookkeeper/issues/4804
### Bug `DefaultEntryLogger.incompleteCompactionLogs()` recovers transactional compaction logs from `*.compacted` files after a restart. The recovered log id is parsed from a hex entry-log filename, but the final recovered `.log` path is rebuilt with the id's decimal string. Entry log filenames are hex-based. When the recovered log id has different decimal and hex representations, recovery can target the wrong final filename. For example: - log id `10` should recover to `a.log`, but recovery can target `10.log` - log id `16` should recover to `10.log`, but recovery can target `16.log` ### Impact After a bookie restart, a compacted entry log may be made available under the wrong decimal filename. The rest of `DefaultEntryLogger` expects the hex filename for that log id, so the recovered compaction log may not be scanned and finalized correctly. This can leave the compacted marker and the old source entry log behind, blocking disk space reclamation for that compaction. It does not rewrite ledger entries or change entry contents; the primary impact is failed compaction recovery and unreclaimed entry log files for the affected compaction log. ### Expected behavior Recovered compaction logs should always use the same hex entry-log filename format as normal entry logs. ### Related fix The fix should rebuild the recovered final `.log` filename with the existing hex log id formatting helper and cover log ids where decimal and hex names diverge, such as `10` and `16`. -- 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]
