Affected tests:
tests/integration/test_mysql_protocol/test.py::test_mysql_dotnet_client
Affected jobs / branches:
Integration tests (*_tsan, N/6) and other integration shards on stable-25.8 — 4 concurrent failures on run 28837216389, commit 29f8caa8140. Previous run passed.
Affected files (Altinity-fork only):
tests/integration/test_mysql_protocol/test.py — missing the upstream cd /testapp && anchor.
Description
test_mysql_dotnet_client failed deterministically (same error, 4/4 shards) on stable-25.8 with:
Error: Received unknown response i for SSLRequest (expecting S or N)
Not caused by the two PRs merged since the last green run (Altinity/ClickHouse#2008 and #2009 — both CI/report-only). Not flaky either — the wording SSLRequest (expecting S or N) is PostgreSQL Npgsql handshake vocabulary, not MySQL, so the dotnet client is talking the wrong protocol against port 9001.
Root Cause
Upstream PR ClickHouse/ClickHouse#80785 added a PostgreSQL C# client to the same Dockerfile and left WORKDIR /pg_testapp as the last directive. That PR was later reverted in ClickHouse/ClickHouse#105615, but the published altinityinfra/mysql_dotnet_client:latest image on Docker Hub retained the wrong WORKDIR, and tests/integration/compose/docker_compose_mysql_dotnet_client.yml has no pull_policy: always. The test runs dotnet run -- ... without cding, so on runners that pulled the poisoned :latest, dotnet executes the Npgsql project against the MySQL port. The byte 'i' (0x69 = 105) is the length prefix of ClickHouse's MySQL handshake being misread by Npgsql.
That explains the flip: previous run's runners had the older cached image; the runners on run 28837216389 pulled the poisoned one.
Upstream fix ClickHouse/ClickHouse#105636 (commit 7f7a222b1a8, 2026-05-22) anchors the command to /testapp:
- f"dotnet run -- --host {node.hostname} ..."
+ f"cd /testapp && dotnet run -- --host {node.hostname} ..."
Upstream backported it to 25.8.25.7. Altinity's stable-25.8 is currently based on v25.8.23.13-lts, so the fix has not reached us yet.
Suggested Solution
No dedicated cherry-pick planned — the fix will land automatically when stable-25.8 is rebased onto 25.8.28. Tracking here so the failure isn't re-triaged.
References
Affected tests:
tests/integration/test_mysql_protocol/test.py::test_mysql_dotnet_clientAffected jobs / branches:
Integration tests (*_tsan, N/6)and other integration shards onstable-25.8— 4 concurrent failures on run 28837216389, commit29f8caa8140. Previous run passed.Affected files (Altinity-fork only):
tests/integration/test_mysql_protocol/test.py— missing the upstreamcd /testapp &&anchor.Description
test_mysql_dotnet_clientfailed deterministically (same error, 4/4 shards) onstable-25.8with:Not caused by the two PRs merged since the last green run (Altinity/ClickHouse#2008 and #2009 — both CI/report-only). Not flaky either — the wording
SSLRequest (expecting S or N)is PostgreSQL Npgsql handshake vocabulary, not MySQL, so the dotnet client is talking the wrong protocol against port 9001.Root Cause
Upstream PR ClickHouse/ClickHouse#80785 added a PostgreSQL C# client to the same Dockerfile and left
WORKDIR /pg_testappas the last directive. That PR was later reverted in ClickHouse/ClickHouse#105615, but the publishedaltinityinfra/mysql_dotnet_client:latestimage on Docker Hub retained the wrong WORKDIR, andtests/integration/compose/docker_compose_mysql_dotnet_client.ymlhas nopull_policy: always. The test runsdotnet run -- ...withoutcding, so on runners that pulled the poisoned:latest,dotnetexecutes the Npgsql project against the MySQL port. The byte'i'(0x69 = 105) is the length prefix of ClickHouse's MySQL handshake being misread by Npgsql.That explains the flip: previous run's runners had the older cached image; the runners on run 28837216389 pulled the poisoned one.
Upstream fix ClickHouse/ClickHouse#105636 (commit
7f7a222b1a8, 2026-05-22) anchors the command to/testapp:Upstream backported it to
25.8.25.7. Altinity'sstable-25.8is currently based onv25.8.23.13-lts, so the fix has not reached us yet.Suggested Solution
No dedicated cherry-pick planned — the fix will land automatically when
stable-25.8is rebased onto25.8.28. Tracking here so the failure isn't re-triaged.References
7f7a222b1a8