ArafatKhan2198 opened a new pull request, #11933: URL: https://github.com/apache/ozone/pull/11933
### **What changes were proposed in this pull request?** On startup, Recon rebuilds its derived tables only if a task's sequence number is **behind** the OM sync sequence number. But the OM sequence number can go **backwards**, for example after OM is restored from a backup. **Example:** 1. Recon has synced OM and built its tables up to **1000**. 2. OM is restored from an older backup and is now at **600**. 3. Recon falls back to a full snapshot, saves the OM sync number as **600**, and queues a rebuild. The rebuild request is kept only in memory. 4. Recon restarts before the rebuild finishes, so the request is lost. 5. On startup: is 1000 *behind* 600? No, so Recon skips the rebuild and keeps showing data from the old OM. **Fix:** rebuild when the numbers are **different** (`!= 0`) instead of only when the task is behind (`< 0`). The normal cases (behind → rebuild, equal → no rebuild) don't change. The check is moved into a small helper, `getTasksToReprocessOnStartup`, so it can be unit tested. This is rare (OM going back in time *and* a Recon restart during the rebuild), but when it happens the stale data is silent and never fixes itself. ### **What is the link to the Apache JIRA** https://issues.apache.org/jira/browse/HDDS-16462 ### **How was this patch tested?** - New unit test `testStartupReconciliationReprocessesTaskOnLineageRegression` covers ahead, behind and equal. - `TestOzoneManagerServiceProviderImpl` passes (17/17), and checkstyle is clean. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
