)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"05dacb2e2d0cbe90be24fbd7661d21da124f5e8f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7b735101_a49bb031","updated":"2023-02-16 17:05:31.000000000","message":"Yeah, that all looks to work the way I expect.","commit_id":"63e618b232c5f1a50e16baa0e685f4e25716f737"}],"test/unit/obj/test_server.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"05dacb2e2d0cbe90be24fbd7661d21da124f5e8f","unresolved":true,"context_lines":[{"line_number":6635,"context_line":"            environ\u003d{\u0027REQUEST_METHOD\u0027: \u0027POST\u0027},"},{"line_number":6636,"context_line":"            headers\u003d{\u0027X-Timestamp\u0027: normalize_timestamp(the_time)})"},{"line_number":6637,"context_line":"        resp \u003d req.get_response(self.object_controller)"},{"line_number":6638,"context_line":"        self.assertEqual(resp.status_int, 404)"},{"line_number":6639,"context_line":""},{"line_number":6640,"context_line":"        # ...unless sending an x-backend-replication header...which lets you"},{"line_number":6641,"context_line":"        # modify x-delete-at"}],"source_content_type":"text/x-python","patch_set":1,"id":"e3a69ae7_73c93fda","line":6638,"updated":"2023-02-16 17:05:31.000000000","message":"I feel like this should have included some assertions about the on-disk files. Like, on the face of it, it might seem \"reasonable\" for the object-server to quietly replace the .data with a .ts based on the x-delete-at -- but we don\u0027t, giving replication/reconstruction a chance to amend it as below.\n\n...which makes it a little surprising that we don\u0027t have some configurable delay on the expirer. I sense a race between reconstructor and expirer that could lead to dark data that can\u0027t be reconstructed :-/","commit_id":"63e618b232c5f1a50e16baa0e685f4e25716f737"}]}