Sema Checherinda

proof https://s3.amazonaws.com/clickhouse-test-reports/json.html?PR=81787&sha=2ec35a60576a7240b91fca93f74b660a114983dd&name_0=PR&name_1=Unit%20tests%20%28asan%29 ``` [ RUN ] DiskObjectStorageTest.RewriteFileTxUndo create_metadata_callback path WriteFileTxCommit_file key_ local_blob_storage_dir/ymfhclghzlwvafrtuouahbywoquimrys create_metadata_callback on execute MetadataStorageFromDiskTransaction createMetadataFile path WriteFileTxCommit_file object_key local_blob_storage_dir/ymfhclghzlwvafrtuouahbywoquimrys size 30 DiskObjectStorageTransaction writeFile WriteFileTxUndo_file mode Rewrite auto commit...

I need to check fast tests. But the main part is completed here.

This is related to public version as well. ``` 2025.08.04 22:17:17.707686 [ 2228 ] {fcdf9f3e-cd71-4e0f-8372-182cbf57e3ad::201403_1_6_1} TruncateFileObjectStorageOperation: Truncate file operation for path 'store/fcd/fcdf9f3e-cd71-4e0f-8372-182cbf57e3ad/tmp_merge_201403_1_6_1/ParsedParams.size0.bin' resulted in removing objects: store/fcd/fcdf9f3e-cd71-4e0f-8372-182cbf57e3ad/tmp_merge_201403_1_6_1/ParsedParams.size0.bin -> s3/hyq/tdajrxbdaedswveaxtezzhmmckcup ```...

Will look one more time.

It might be that connection attempts are run out of count and connection is destroyed after use. Our default for s3 disks is 100. Not such a rare chance. Also...

However there are several parts in the test. It uses 16 connections. It is not likely that all read requests are `DiskConnectionsExpired`.

There are some failures occur still. Like that https://github.com/ClickHouse/ClickHouse/pull/46052 In my PR test_format_with_prefix_and_suffix https://s3.amazonaws.com/clickhouse-test-reports/45889/e0db071563a787c35a3325fa07691231ac1ceab4/integration_tests__asan__[4/6].html Also I found in the history test_block_based_formats_1 https://s3.amazonaws.com/clickhouse-test-reports/0/33877b5e006d48116854a9c0b64d7026013649f0/integration_tests__release__[2/2].html test_row_based_formats https://s3.amazonaws.com/clickhouse-test-reports/46009/654e42c1706ae5e72868c30f2ddaae46d4365fb7/integration_tests__release__[2/4].html https://s3.amazonaws.com/clickhouse-test-reports/0/3e3df376c0c6c33b7b008df9241b6e55a30a48c7/integration_tests__release__[2/2].html

It looks strange here: case: https://d1k2gkhrlfqv31.cloudfront.net/clickhouse-test-reports-private/0/eb845094dc565f2d7fb7247e946c203bb3eb256c/stateless_tests__release__s3_storage__%5B1_2%5D.html key: `tea-first-random-part/s3-disk/new-style-prefix/etk/zdrbyxtkzifydieexuzycxuwsajap` ch date from log: `2024.08.06 14:58:46.430079` date header in responce: `Tue, 06 Aug 2024 09:13:46 GMT` diff (ch - mino): `3h, 45m...

> > ch date from log: 2024.08.06 14:58:46.430079 > > date header in responce: Tue, 06 Aug 2024 09:13:46 GMT > > diff (ch - mino): 3h, 45m и 0.430079s...

It might be harder then I thought. It is not so easy to understand if the select results are sorted.