All committers have signed the CLA.

@alexey-milovidov I believe this is ready for review

@azat would love a review too

Workflow [PR], commit [9177b92]

Summary: ❌

@novikd I addressed all of the comments, and I believe the failing tests are just flaky

Stateless tests (amd_binary, old analyzer, s3 storage, DatabaseReplicated, sequential)

Looks related.

@novikd I applied the requested changes and the test failed doesn't include my tests

@novikd A gentle reminder

@novikd Tests look fine all the failing ones are not related to the PR too

This has completely broken 02046_remote_table_function_named_collections everywhere. I'm reverting ASAP

Side note: The problems with 02046_remote_table_function_named_collections were visible in CI. Let's check carefully before merging.

@rschu1ze @Algunenano , I will open another PR to fix the interactions between this and 02046 or we can use this PR ?

Side note: The problems with 02046_remote_table_function_named_collections were visible in CI. Let's check carefully before merging.

@rschu1ze I checked CI before merging. The error message is generic, and it was not clear that it was caused by this change. This PR does not change anything around the named collections.

I will open another PR to fix the interactions between this and 02046 or we can use this PR ?

You can open another PR once Revert is merged.

I checked CI before merging. The error message is generic, and it was not clear that it was caused by this change. This PR does not change anything around the named collections.

@novikd there's a very useful cidb link for every faild test in the report (and if you checked this link, you might have noticed that this test wasn't flaky before), and also retry_failed tag which indicates that the test is broken and not just flaky. Moreover, the test has failed in every Stateless tests run. Didn't you find this suspicious when checking the CI?

@novikd moreover, looks like this PR also breaks test_storage_postgresql: cidb

@tavplubix, as you may notice, errors in both 02046_remote_table_function_named_collections and test_storage_postgresql have the same message:
Unexpected key A in named collection. Required keys: addresses_expr, host, hostname, table, optional keys: database, db, password, port, sharding_key, username, user.

So it was clear that the root cause of these failures was the same. So I decided that it is also unrelated.

@novikd there's a very useful cidb link for every faild test in the report (and if you checked this link, you might have noticed that this test wasn't flaky before), and also retry_failed tag which indicates that the test is broken and not just flaky. Moreover, the test has failed in every Stateless tests run. Didn't you find this suspicious when checking the CI?

I found it suspicious, but it is still unclear to me why named collections are dependent on function resolution. I checked the CI report and even fixed one test failure myself: 9177b92.

I don't quite understand why this mistake requires so much attention and passive-aggressive messages. I agreed that I made a mistake and the PR was reverted. There were visible actions on my part indicating that I was reviewing the CI reports.

This is the first PR with broken CI checks I merged in months, so it is obviously a one-time mistake that I regret (I actually don't remember doing something like this in 2025, but it's not the point).

I don't think that public shaming or passive-aggression would improve the state of our CI.

Dima, I'm sorry, I didn't mean to blame you for a mistake, mistakes happen, and it's okay. Especially when we have a lot of unrelated failures and flaky or even broken tests in general, it's easy to miss something like this

I just wanted to highlight some features of the CI that can help to avoid such mistakes. Because in most cases it happens exactly when a failure looks unrelated, but appears to be actually related for some reason. If a test was never flaky before but then suddenly failed in all checks in the PR - it has to be investigated before merging. Another option (which I personally don't like, but many people do it) is to merge master and rerun CI to make sure that it's unrelated

It's a very good question why named collections depend on function resolution

@tavplubix I am trying to fix this problem of dependency now and re submit the PR it is my fault after all @novikd was just helping me and I am grateful for that. I am just nee to the CI system this only my 3rd PR, but I will get this fixed and merged back again

It's nobody's fault, shit happens