)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"2edfc42b71ac9b8d31e78c3926c1ca83de8d5717","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"998cf081_4f2e87a1","updated":"2025-12-15 20:50:53.000000000","message":"I think this isn\u0027t really any worse than before -- maybe some failures become a little less obvious about what\u0027s going on (since we lose the obviousness of something like `\u0027Thu, 01 Jan 1970 00:00:01 GMT\u0027 !\u003d \u0027Thu, 01 Jan 1970 00:00:03 GMT\u0027` WRT which timestamp we\u0027re looking at relative to other timestamps in the test) but we can always improve our output if/when it comes up.\n\nI\u0027m not sure the comments make a strong case for `.normal` though -- that `fake_http_connect` jig is funky.","commit_id":"131c8b8680b3258660b3f82f8704fa039c6a7b57"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"9ea0a1c21c6ce4260892d6325662eaf4027faf8d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"636463fe_5567bb10","updated":"2025-12-18 18:50:07.000000000","message":"moving this to WIP because it may not be necessary if I make Timestamp.zero() backwards compatible/comparable with legacy timestamps","commit_id":"ce7692a4cbc03406c57e09f8ddfce360530d3d02"}],"test/unit/proxy/test_server.py":[{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"2edfc42b71ac9b8d31e78c3926c1ca83de8d5717","unresolved":true,"context_lines":[{"line_number":5154,"context_line":""},{"line_number":5155,"context_line":"    def test_HEAD_newest(self):"},{"line_number":5156,"context_line":"        with save_globals():"},{"line_number":5157,"context_line":"            # response x-timestamp is normal format"},{"line_number":5158,"context_line":"            ts \u003d [next(self.ts_iter).normal for _ in range(4)]"},{"line_number":5159,"context_line":""},{"line_number":5160,"context_line":"            def test_status_map(statuses, expected, ts_indexes, exp_ts_index):"}],"source_content_type":"text/x-python","patch_set":2,"id":"2f47073f_3793e3bc","line":5157,"updated":"2025-12-15 20:50:53.000000000","message":"Yes... but...\n\nIt\u0027s not entirely clear to me how the `timestamps` kwarg to `set_http_connect`/`fake_http_connect` should be used. I think the clearest guidance comes from `FakeConn`, where we say\n```\n# tests may specify int, string, Timestamp or None\n```\nwhich tells us next to nothing. Then later in `getheaders` we throw the exact same value into `x-timestamp` (which should use normal), `x-backend-timestamp` (which should use internal), *and* `last-modified` (which should be an RFC date!) and I\u0027m more confused than ever.","commit_id":"131c8b8680b3258660b3f82f8704fa039c6a7b57"},{"author":{"_account_id":34930,"name":"Jianjian Huo","email":"jhuo@nvidia.com","username":"jhuo"},"change_message_id":"60f9605bd1111661f189afcd60817157219a1552","unresolved":true,"context_lines":[{"line_number":5154,"context_line":""},{"line_number":5155,"context_line":"    def test_HEAD_newest(self):"},{"line_number":5156,"context_line":"        with save_globals():"},{"line_number":5157,"context_line":"            # response x-timestamp is normal format"},{"line_number":5158,"context_line":"            ts \u003d [next(self.ts_iter).normal for _ in range(4)]"},{"line_number":5159,"context_line":""},{"line_number":5160,"context_line":"            def test_status_map(statuses, expected, ts_indexes, exp_ts_index):"}],"source_content_type":"text/x-python","patch_set":2,"id":"aa234766_6a6cd318","line":5157,"in_reply_to":"2f47073f_3793e3bc","updated":"2025-12-18 04:16:19.000000000","message":"yes, ``fake_http_connect`` use this normal format timestamp for all three things:\nhttps://github.com/NVIDIA/swift/blob/master/test/unit/__init__.py#L930-L940\n\nis there a patch to fix ``fake_http_connect`` already?","commit_id":"131c8b8680b3258660b3f82f8704fa039c6a7b57"},{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"7f6ac138347dca60696787877e79432080c4ea9e","unresolved":true,"context_lines":[{"line_number":5154,"context_line":""},{"line_number":5155,"context_line":"    def test_HEAD_newest(self):"},{"line_number":5156,"context_line":"        with save_globals():"},{"line_number":5157,"context_line":"            # response x-timestamp is normal format"},{"line_number":5158,"context_line":"            ts \u003d [next(self.ts_iter).normal for _ in range(4)]"},{"line_number":5159,"context_line":""},{"line_number":5160,"context_line":"            def test_status_map(statuses, expected, ts_indexes, exp_ts_index):"}],"source_content_type":"text/x-python","patch_set":2,"id":"376472c2_7bb3049f","line":5157,"in_reply_to":"aa234766_6a6cd318","updated":"2025-12-18 13:19:54.000000000","message":"It took me a long time to figure out why these tests failed when we moved to a v2 timestamp:\n\n* the fake responses are intended to provide for 1x account HEAD, 1 x container HEAD and 3 x obj HEAD.\n* when the v2 timestamp patch is applied, the first N fake responses are consumed by account HEAD while the timestamp is \u00270\u0027 !?!\n* I finally pinned that down to this code https://github.com/openstack/swift/blob/0ceff0fd5f433209593fa7b4056fa0bdeb2146ce/swift/proxy/controllers/base.py#L1602-L1616 where the response timestamp is compared to Timestamp.zero():\n* a v2 Timestamp.zero().internal is 0000000000.00000_2000000000000000 \n* whereas Timestamp(\u00270\u0027).internal is 0000000000.00000 (it\u0027s parsed as a legacy timestamp)\n\n* So Timestamp(\u00270\u0027) is in fact \u003c Timestamp.zero(), and the response is discarded in the account HEAD, and another response is consumed until we get to a Timestamp(\u00271\u0027)\n* which means there are insufficient responses to satisfy the x-newest obj HEAD and the test setup is broken\n\nSo the \u0027fix\u0027 I\u0027ve made is actually not due to the format of the timestamps, but the value, because I\u0027m now picking timestamps \u003e\u003e 0 from self.ts_iter.\n\n**I\u0027m now reflecting on whether that fix is disguising the fact that even in a v2 timestamp world, a legacy Timestamp(\u00270000000000.00000\u0027) SHOULD equal Timestamp.zero() 😕 **\n\nThe format change made in this patch is just reasonableness: there is no real world x-timestamp header that has the form \u00270\u0027, \u00271\u0027 or \u00272\u0027. X-Timestamp uses the normal format ``%016.5f``. So it makes no sense to write a test response with ``X-Timestamp: \u00270\u0027``, but of course that\u0027s happened because timestamps have been so loosely defined. And a large part of all the patches that have gone before this in the chain of test cleanup has been migrating tests to use timestamp headers that actually represent what is happening in the real world. \n\nThe side-show here is that ``fake_http_connect`` is indeed a mess, and is returning the wrong format for x-backend-timestamp etc. I once started trying to improve fake_http_connect https://review.opendev.org/c/openstack/swift/+/930595, although that patch didn\u0027t address the response headers.\n\nAnd maybe I lifted the lid off that can of worms with this comment\n\n``# response x-timestamp is normal format``\n\nwhich IS true, but belies the incorrect handling of the *other* headers by fake_http_connect.","commit_id":"131c8b8680b3258660b3f82f8704fa039c6a7b57"}]}