)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":7847,"name":"Alistair Coles","email":"alistairncoles@gmail.com","username":"acoles"},"change_message_id":"c584115b8263810fa85f21d469ce494de180663c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f8c022a4_9cb64f7f","updated":"2025-03-19 09:02:22.000000000","message":"@clay fair critique - I kinda rushed this out. Will abandon.","commit_id":"6839e8b5c5290878f65833a8dd69777e0fdabe06"},{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"a4a693bce710282962c8678916cf143070c804a8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ff97e479_783286e2","updated":"2025-03-18 16:50:12.000000000","message":"I\u0027d prefer to +A the patch that pins the boto3 requirement if that exists; I also seem to imagine an update to this test suite floating around that adds a \"custom s3 client\" that\u0027s not boto (which might be a good candidate for documenting how aws/s3api behave when they get weird requests from obscure/old clients)","commit_id":"6839e8b5c5290878f65833a8dd69777e0fdabe06"}],"test/s3api/test_object_checksums.py":[{"author":{"_account_id":1179,"name":"Clay Gerrard","email":"clay.gerrard@gmail.com","username":"clay-gerrard"},"change_message_id":"a4a693bce710282962c8678916cf143070c804a8","unresolved":true,"context_lines":[{"line_number":314,"context_line":"        code \u003d resp[\u0027ResponseMetadata\u0027][\u0027HTTPStatusCode\u0027]"},{"line_number":315,"context_line":"        self.assertEqual(400, code)"},{"line_number":316,"context_line":"        self.assertEqual(\u0027InvalidRequest\u0027, resp[\u0027Error\u0027][\u0027Code\u0027])"},{"line_number":317,"context_line":"        if Version(botocore.__version__) \u003c Version(\u00271.36\u0027):"},{"line_number":318,"context_line":"            exp \u003d \u0027Expecting a single x-amz-checksum- header\u0027"},{"line_number":319,"context_line":"        else:"},{"line_number":320,"context_line":"            exp \u003d \u0027Value for x-amz-sdk-checksum-algorithm header is invalid.\u0027"}],"source_content_type":"text/x-python","patch_set":1,"id":"fb233f6b_7eb7af3c","line":317,"updated":"2025-03-18 16:50:12.000000000","message":"at a glance this reads like a backwards coupling... we\u0027re testing the *server* - so \"what changed\" isn\u0027t *actually* the \"client version\" but the specific request params that happened to be sent by that client version.\n\nIdeally we\u0027d have two tests that say:\n\n* if you send a request like THIS you get \"expecting a single x-amz-checksum\"\n* if you send a request like THIS you get \"value for x-amz-checksum invalid\"\n\nbut our cross-compat client of choice isn\u0027t condusive to writing those kinds of tests because...\n\nthe request that is sends doesn\u0027t depend on the params as much as the version number, but I don\u0027t really want to test the client - even tho it IS super helpful to document how you can expect this popular sdk to behave when talking to s3api!\n\nI think we should pin boto3 and hopefully it\u0027s not to burdensome to keep our assertions up-to-date with the latest client request params.\n\nRather than \"documenting expectations with old versions of boto3\" - I think we\u0027d be better off branching into a: use a custom client with more request param control and document how the server responds if ANY client makes \"a request like THIS\"","commit_id":"6839e8b5c5290878f65833a8dd69777e0fdabe06"}]}