RockteMQ-AI commented on issue #11403: URL: https://github.com/apache/rocketmq/issues/11403#issuecomment-6141132539
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported issue has been verified against the current codebase (commit `a7edeecfb`). **Root Cause:** `transferToFsStore()` discards the `PutMessageResult` of each checkpoint put and deletes the scanned KV records unconditionally, so any failed revive-topic put silently loses in-flight messages. **Impact:** Silent data loss of in-flight POP messages during KV→FS migration. The sibling `revive()` path (PopConsumerService.java:624-644) shows the intended pattern: collect failures, write backoff retry records, only then delete. `transferToFsStore()` does not follow this pattern. **Severity:** High — requires operator-initiated `transferToFsStore` admin command to coincide with store put failures, so the exposure window is narrower than an always-on path, but the consequence is permanent message loss. **Key findings from code verification:** 1. ✅ `asyncPutMessage().join()` return value is discarded (line 800) 2. ✅ `deleteRecords()` is called unconditionally (line 803) — `asyncPutMessage` never completes exceptionally for put failures, so failures are silently swallowed 3. ✅ `catch (Throwable)` only logs; `while(true)` rescans forever inside `synchronized` method (no sleep on exception path → busy-spin) 4. ✅ Log line reports scanned count as transferred regardless of put success An automated fix proposal will be generated. Reply `/approve` to proceed with PR generation. --- *Automated evaluation by RockteMQ-AI* -- 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]
