[client-v2] Enum label parsing: backslash escapes in a type name are decoded by dropping the backslash, so labels with a newline, tab or NUL are wrong

Aberta
  • Algo errado?
#3,348 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
Meio dia
Facilidade para iniciantes
64/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
java
Domínio
databases

Direção de pesquisa

Start in ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java, around line 511), which ClickHouseEnum uses to decode Enum8/Enum16 labels from type strings. Replace the drop-the-backslash rule with the server's escape mapping, keeping unknown escapes intact and not consuming digits after \0. Run the existing ClickHouseUtilsTest and ClickHouseColumnTest, plus the issue's parser examples such as Enum8('a\nb' = 1) expecting label a LF b. Done when those examples decode correctly and the existing tests still pass.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

Describe the bug

ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java:511-540) is used by ClickHouseEnum to decode Enum8 / Enum16 labels out of a type string (ClickHouseEnum.java:46). It does not implement the server's string-literal escape rules: for any backslash-X sequence it simply drops the backslash and keeps X.

The server writes control characters in a type name as C-style escapes. SELECT toTypeName(CAST(1 AS Enum8('a\nb' = 1))) returns the type string Enum8('a\nb' = 1) where \n is backslash + n, and the real label is a LF b. The client decodes that to the 3-character string anb.

So for every enum label that contains a control character, the client silently returns a label that is different from the one the server stores, and an insert with the correct label throws because the label is not in the map.

What is right and what is wrong today, for the type strings the server itself emits:

Type string from the server Server label (hex) Client label (hex)
Enum8('a\nb' = 1) 610A62 616E62 (anb) wrong
Enum8('a\tb' = 1) 610962 617462 (atb) wrong
Enum8('a\0b' = 1) 610062 613062 (a0b) wrong
Enum8('a\\zb' = 1) 615C7A62 (a\zb) 615C7A62 ok
Enum8('it\'s' = 1) 69742773 (it's) 69742773 ok

Only the doubled backslash and the escaped quote happen to come out right, because for those two the server rule and "drop the backslash" agree. \a, \b, \e, \f, \n, \r, \t, \v, \0, \xHH are all decoded wrong, and an escape the server keeps verbatim loses its backslash.

The same decoder is on both sides of the round trip, so getEnumConstants().value("a\nb") (the insert path, SerializerUtils.java:865) also fails for a label the server really has.

This is the Java counterpart of ClickHouse/clickhouse-cs#729 (that client uses .NET Regex.Unescape, a different wrong rule with a partly different symptom set).

ClickHouse server version

26.10.3.7, verified against a running server.

Reproduction

End-to-end, client-v2 over HTTP (TestNG, client-v2/src/test/java/...):

package com.clickhouse.client;

import com.clickhouse.client.api.Client;
import com.clickhouse.client.api.query.GenericRecord;
import org.testng.Assert;
import org.testng.annotations.Test;

import java.util.List;

public class EnumEscapeTest {
    private static String hex(String s) {
        StringBuilder sb = new StringBuilder();
        for (char c : s.toCharArray()) {
            sb.append(String.format("%02X", (int) c));
        }
        return sb.toString();
    }

    @Test(groups = { "unit" })
    public void testEnumLabelWithNewline() throws Exception {
        try (Client client = new Client.Builder()
                .addEndpoint("http://localhost:8123")
                .setUsername("default").setPassword("")
                .compressServerResponse(false)
                .build()) {
            client.execute("DROP TABLE IF EXISTS scratch_enum_nl").get();
            client.execute("CREATE TABLE scratch_enum_nl (e Enum8('a\\nb' = 1)) ENGINE = Memory").get();
            client.execute("INSERT INTO scratch_enum_nl VALUES (1)").get();

            List<GenericRecord> serverSide = client.queryAll("SELECT hex(toString(e)) AS h FROM scratch_enum_nl");
            String serverHex = serverSide.get(0).getString("h");

            List<GenericRecord> clientSide = client.queryAll("SELECT e FROM scratch_enum_nl");
            String clientLabel = clientSide.get(0).getString("e");

            Assert.assertEquals(hex(clientLabel), serverHex);
        }
    }
}

Result:

java.lang.AssertionError: expected [610A62] but found [616E62]

Expected 610A62 (a, LF, b) — what the server stores. Actual 616E62 (anb).

Parser-level, no server needed (clickhouse-data, these are the exact type strings toTypeName() returns):

ClickHouseColumn.of("e", "Enum8('a\\nb' = 1)").getEnumConstants().name(1);   // "anb",  expected "a\nb"
ClickHouseColumn.of("e", "Enum8('a\\tb' = 1)").getEnumConstants().name(1);   // "atb",  expected "a\tb"
ClickHouseColumn.of("e", "Enum8('a\\0b' = 1)").getEnumConstants().name(1);   // "a0b",  expected "a\0b"
ClickHouseColumn.of("e", "Enum8('a\\\\zb' = 1)").getEnumConstants().name(1); // "a\\zb", ok
ClickHouseColumn.of("e", "Enum8('it\\'s' = 1)").getEnumConstants().name(1);  // "it's",  ok
Suggested fix

In ClickHouseUtils.unescape (clickhouse-data/src/main/java/com/clickhouse/data/ClickHouseUtils.java:511), decode with the server's rules instead of unconditionally dropping the backslash:

  • a doubled quote is one quote (already correct);
  • \a, \b, \e, \f, \n, \r, \t, \v, \0, doubled backslash, escaped quotes and backtick, and \xHH map to their byte values;
  • any other escape keeps the backslash (\z stays \z);
  • \0 never consumes the digits that follow it (\012 is NUL then 12).

unescape is also reached from ClickHouseUtils.readValueArray (ClickHouseUtils.java:1449), so any change there should be checked against the existing ClickHouseUtilsTest / ClickHouseColumnTest cases.

Link

Counterpart issue in the .NET client: https://github.com/ClickHouse/clickhouse-cs/issues/729

Linguagem predominante
Java
Estrelas
1.6k
Forks
649
Merge médio
1d 20h
PRs com merge (30d)
39

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ClickHouse/clickhouse-java

Todas as issues de ClickHouse/clickhouse-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.