)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"ad973fb9e69d0aacd0f7fd8ad97b0297e9966ce8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"712f6ab6_7da9e6a5","updated":"2026-10-19 18:40:20.000000000","message":"I think we now have sufficient evidence to show that an \"incomplete\" routing table in a root can produce a \"filler\" row and that it\u0027d be better in that case if the timestamp was zero.\n\nHowever, in my exploration it seemed like the \"realistic\" reproduction of this scenario required some fairly extensive orchestration of uncorrelated failures:\n\n1011345: Keep stored-OSR-derived routing fillers replaceable | https://review.opendev.org/c/openstack/swift/+/1011345\n\nTherefore, I would LIKE to extrat some signal to deterime prioritization by answering \"has this actually happened in prod\" - I think it would be useful to prioritize this feedback *initially* since this parent change doesn\u0027t fix existing overlaps:\n\n1011344: Warn about conflicting shard range bounds during replication | https://review.opendev.org/c/openstack/swift/+/1011344\n\nMy main reservation about the parent change isn\u0027t \"fixing filler\u0027s to use zero\" (which seems useful somewhat regardless of if it actually happens) but rather that it *reverts* some \"useful\" (???) attempts to seperate the api paths that select \"routing\" shard-ranges from the normal shard range getters.\n\nPerhaps more important than *any* of this would be to stop writing down routing ranges as authoratative:\n\n1005823: do not persist routing metadata while moving misplaced objects | https://review.opendev.org/c/openstack/swift/+/1005823","commit_id":"72e3e2472593188944ab74712bddec6527cde731"}],"test/probe/test_sharder.py":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"ad973fb9e69d0aacd0f7fd8ad97b0297e9966ce8","unresolved":true,"context_lines":[{"line_number":4684,"context_line":"        partial_broker.update_metadata(metadata)"},{"line_number":4685,"context_line":"        partial_broker.merge_shard_ranges([real_osr] + prefix)"},{"line_number":4686,"context_line":"        # X-Newest must choose the partial replica, even while a healthy"},{"line_number":4687,"context_line":"        # third root replica remains available for subsequent recovery."},{"line_number":4688,"context_line":"        self.assertGreater(partial_broker.get_info()[\u0027created_at\u0027],"},{"line_number":4689,"context_line":"                           info[\u0027created_at\u0027])"},{"line_number":4690,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"9a487197_a34e5b60","line":4687,"updated":"2026-10-19 18:40:20.000000000","message":"Recreating this DB makes the incomplete routing view win X-Newest. That may be a reasonable scenario, but it assumes how the responder acquired this combination of metadata and recency.\n\nIn this test we create the recency by rebuilding the DB, with incompleteness by selectively restoring metadata\n\nIn the interrupted-sharding scenario we reproduced:\n\nhttps://review.opendev.org/c/openstack/swift/+/1011345/1/test/probe/test_sharder.py\n\nthe incomplete view belongs to an older root replica; we isolate it to make it answer the lookup.\n\n... that may not be *strictly* \"better\" (longer test, more setup) - but it does provide at least ONE example of how this routing information could become the \"newest avaiable\" w/o simulating an out-of-date record that is somehow \"newer\"","commit_id":"72e3e2472593188944ab74712bddec6527cde731"}]}