echonesis commented on PR #10879: URL: https://github.com/apache/ozone/pull/10879#issuecomment-5100755557
Thanks @chihsuan for the patch. I may be missing a production call path, but it looks like `truncateTable` is only called during task reprocessing. `ReconTaskControllerImpl.reInitializeTasks()` first calls `getStagedReconDBProvider()`, which deletes the existing .staged directory and creates a new Recon DB. The staged tasks are then constructed against this newly created DB before their reprocess() methods call truncateTable. Would these tables therefore always be empty when truncateTable is reached in production? If so, both the previous per-key deletion and the new deleteRange path would return immediately, and the populated-table test would cover a state that does not occur through the production reprocessing flow. Is there another call path where truncateTable operates on an existing populated DB? Otherwise, would it make more sense to remove the now-redundant truncate calls/helper instead? -- 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]
