[shinzui]

Hi, and thank you for your work on ClickHaskell. I've been using it in an application and encountered a few issues while testing native queries and connection handling. I'm submitting three separate PRs so each can be reviewed independently: query-kind encoding, command/insert status packets, and connection cleanup. I used OpenAI Codex to help with the implementation and tests for these fixes.

This first PR addresses application requests appearing as secondary queries in ClickHouse's query log. The current QueryKind serializer and deserializer use 1/2/3 for NoQuery/InitialQuery/SecondaryQuery, while ClickHouse uses 0/1/2. As a result, mkQueryPacket sends InitialQuery as 2, which the server interprets as SecondaryQuery.

The change corrects both mappings without changing the Haskell constructors or public function signatures.

The query-kind-regressions suite passes on GHC 9.12.4. It checks fixed wire bytes in both directions and rejects invalid values 3 and 255. Fixed expectations catch the shared encoding/decoding error that a round-trip test would miss. I confirmed the suite fails against the unmodified upstream implementation. I haven't run the full compiler matrix or a live-server query-log test for this branch.

Please let me know if you'd prefer a different location for the regression tests.

[KovalevDima]

I think this test is unnecessary. The bug was introduced when porting the protocol spec, and adding tests for individual enum values won't prevent similar mistakes elsewhere.

I'd rather invest in a test proxy between the official clickhouse-client and the server to capture real protocol traffic and check deserialize → serialize round-trips. This would test the protocol more broadly.

[KovalevDima]

@shinzui, nice catch! Thank you very much for the contribution!

[shinzui]

@KovalevDima Thanks for reviewing my PR! Any chance you could take a look at the other two as well? I'm currently vendoring the package because of the issues they address.

I've been working on a project that isn't in production yet, but I'll be doing load testing before deployment. I expect I'll have more PRs once that gets underway.

[KovalevDima]

@shinzui Sure, I'll review the other PRs over the weekend!