)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"1df3bc8e1a4897e7105edae67196c59849a8385f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"657d3ce7_b44e4510","updated":"2024-02-06 19:44:41.000000000","message":"Sure; this seems functionally equivalent. Not sure I get the motivation for the refactor though -- I guess just wanting to slim it down from a list of bools to a single bool? Or was the sticking point around the naming, and it\u0027d be better to call the per-batch flag something like `delete_batch`?","commit_id":"75724fc0899801034c65fe2716479624bd7f7eeb"}],"swift/obj/replicator.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"1df3bc8e1a4897e7105edae67196c59849a8385f","unresolved":true,"context_lines":[{"line_number":580,"context_line":"                                             len(delete_objs))"},{"line_number":581,"context_line":"                            _junk, error_paths \u003d self.delete_handoff_objs("},{"line_number":582,"context_line":"                                job, delete_objs)"},{"line_number":583,"context_line":"                            # XXX what does this even *mean*"},{"line_number":584,"context_line":"                            # if replication works for a hand-off device and it"},{"line_number":585,"context_line":"                            # failed, the remote devices which are target of"},{"line_number":586,"context_line":"                            # the replication from the hand-off device will be"}],"source_content_type":"text/x-python","patch_set":1,"id":"f2c4163b_3e3fdf2f","line":583,"updated":"2024-02-06 19:44:41.000000000","message":"Came in with https://github.com/openstack/swift/commit/79ba4a85, looking to get (more? any?) recon stats out of the replicator.\n\nSeems to be saying that\n\n- if we successfully replicate but the delete failed, data will to hang around and get processed again on the next cycle,\n- since there was a failure and we want to track failures, in such a case we\u0027ll flag the remote disk despite it being a local problem (!!), and\n- it\u0027s reasonably likely that we\u0027ll continue flagging those on subsequent passes (since it was a local error trying to clean up).\n\nSeems like a questionable strategy (why aren\u0027t we quarantining!?) but orthogonal to the batching.","commit_id":"75724fc0899801034c65fe2716479624bd7f7eeb"}]}