`/:idx/_count` doesn't work with indexes stored in `quesma_common_table`

[nablaone]

Calling _count endpoint on indexes stored in quesma_common_table ends up with an error:

GET http://localhost:8080/accesslog_20250131/_count

HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
X-Quesma-Source: Clickhouse
X-Quesma-Table-Resolver: Pass to clickhouse. Table: 'quesma_common_table' . Common table. Indexes: [accesslog_20250131]. Pass to Elasticsearch. Enable AB testing. Common table will be used. (commonTable).
Date: Fri, 31 Jan 2025 11:26:20 GMT
Content-Length: 120

Internal Quesma Error.
Please contact support if the problem persists.
Request ID: 0194bc1c-9f80-7e3c-bbed-1fe080de9023


Response code: 500 (Internal Server Error); Time: 46ms (46 ms); Content length: 120 bytes (120 B)

Logs:

quesma-1  | Jan 31 11:26:20.066 ERR quesma/frontend_connectors/dispatcher.go:277 > Error processing request: clickhouse: query row failed: code: 60, message: Unknown table expression identifier 'accesslog_20250131' in scope SELECT count(*) FROM accesslog_20250131 opaque_id= path=/accesslog_20250131/_count request_id=0194bc1c-9f80-7e3c-bbed-1fe080de9023
quesma-1  | Jan 31 11:26:20.067 ERR quesma/frontend_connectors/dispatcher.go:134 > quesma request failed: clickhouse: query row failed: code: 60, message: Unknown table expression identifier 'accesslog_20250131' in scope SELECT count(*) FROM accesslog_20250131 opaque_id= path=/accesslog_20250131/_count reason="Failed request." request_id=0194bc1c-9f80-7e3c-bbed-1fe080de9023

[trzysiek]

I can fix that after merge of #1261

[trzysiek]

TL;DR - WIP 🚧

This one is pretty weird. In my testing I encountered even a bit different behaviour. We use 2 resolvers: first one from newer table_resolver package, which properly returns we should pass the request to common_table, but later program flow goes to LogManager.resolver, which says we don't have such a table testT, thus we don't even send a request to CH.

Below I attach my logs of this behaviour. I'll investigate it further, but slowly.
I'll try to understand our behaviour with 2 resolvers and fix/simplify the logic. Haven't coded it any of 2 resolvers, so it'll take a bit for me to understand it full-ish.

[resolver part (from table_resolver)]:
-----------------------------------------------------------
END input {testT false [testT]} decisions [Pass to clickhouse. Table: 'quesma_common_table' . Common table. Indexes: [testT]. Using default wildcard ('*') configuration for Query processor (defaultWildcard).]

Jul  7 16:38:24.353 ERR ../platform/table_resolver/table_resolver.go:164 > KK Decision for pipeline 'Query', pattern 'testT':  Pass to clickhouse. Table: 'quesma_common_table' . Common table. Indexes: [testT]. Using default wildcard ('*') configuration for Query processor (defaultWildcard). version=development

[LogManager.resolver part]:
LM Resolve 2 pattern: testT 
all schemas: map[quesma_common_table:{map[@timestamp:Field(@timestamp, @timestamp) __quesma_index_name:Field(__quesma_index_name, __quesma_index_name)] map[] true default}]
LM Resolve 3 results []
(empty decision... we don't even query CH)

[trzysiek]

Nvm, we all know table resolver is a pretty complex feature and it's hard to get it right. If no customers report problems with it, let's not change it until they do. Got pretty used with the code there, so I'll gladly tackle it later if needed.

For now #1494 seems to fix the issue completely.