Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

client-v2: serializePrimitiveData rejects or silently corrupts String values for UInt64, UUID, Date and DateTime

Abierto
  • ¿Algo no está bien?
#3,132 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
82/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
databases

Línea de trabajo

Comienza en client-v2/src/main/java/com/clickhouse/client/api/data_formats/internal/SerializerUtils.java, en serializePrimitiveData, y sigue las rutas auxiliares de UInt64, UUID, fecha y fecha-hora. Verifica el comportamiento de conversión existente y la comprobación de rango relacionada de unsigned long en BinaryStreamUtils. Se considera terminado cuando los valores String se gestionen de forma coherente para estos tipos, los valores UInt64 no válidos produzcan un error en lugar de desbordarse silenciosamente y las rutas signed o numéricas existentes permanezcan sin cambios.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:data-type bug client-api-v2 jdbc-v2

Summary

SerializerUtils.serializePrimitiveData accepts String input for most scalar column types via the convertToInteger / convertToLong / convertToBigInteger / convertToBigDecimal / convertToString helpers, but a subset of types either reject a String outright or — for UInt64 — silently corrupt it. This makes String coercion inconsistent across the type switch.

Line references are against 0.9.5, file client-v2/src/main/java/com/clickhouse/client/api/data_formats/internal/SerializerUtils.java.

Behaviour today

Column type String input Result
Int8/16/32, UInt8/16, Int64, UInt32 convertToInteger / convertToLong works
Int128/256, UInt128/256 convertToBigInteger works
Decimal* convertToBigDecimal works
String, FixedString convertToString works
UInt64 (:522) convertToLong → Long.parseLong (:760) throws above 2^63-1; silently wraps a negative
UUID (:575) (UUID) value ClassCastException
Date, Date32 (:553, :556) writeDate / writeDate32 (:1105) IllegalArgumentException: Cannot convert … to Long
DateTime, DateTime64 (:559, :563) writeDateTime / writeDateTime64 (:1141) same
The UInt64 case is a silent-corruption bug
convertToLong("-1")      // -> -1L        (Long.parseLong, signed)
writeUnsignedInt64(-1L)  // -> writeInt64 -> FF FF FF FF FF FF FF FF

ClickHouse reads that back as 18446744073709551615. So a negative String is written as the maximum UInt64 with no error.

This is already inconsistent within the library: BinaryStreamUtils.writeUnsignedInt64(OutputStream, BigInteger) range-checks via ClickHouseChecker.between(value, TYPE_BIG_INTEGER, BigInteger.ZERO, U_INT64_MAX), so a BigInteger of -1 is correctly rejected. Only the String path wraps.

Values in [2^63, 2^64-1] are legal UInt64 values and are encodable on the wire (writeUnsignedInt64(long) just emits the raw 8 bytes), but unreachable through the String path.

Proposed fix

  1. UInt64 — use an unsigned-aware conversion at :522 rather than changing the shared convertToLong, which Int64 (:504) and UInt32 (:519) also use and which needs signed parsing:
/** UInt64 runs past Long.MAX_VALUE; the returned long carries the raw bit pattern. */
public static Long convertToUnsignedLong(Object value) {
    if (value instanceof String) {
        return Long.parseUnsignedLong((String) value);
    }
    return convertToLong(value);
}
  1. UUID — add a String branch using UUID.fromString.
  2. Date / Date32 / DateTime / DateTime64 — add a String branch in the writeDate / writeDate32 / writeDateTime / writeDateTime64 helpers, which already dispatch on LocalDate / ZonedDateTime / OffsetDateTime / Timestamp. Fixing them there also covers their other callers.
Backward compatibility

Items 2 and 3 are purely additive: those inputs throw today, so nothing that currently succeeds changes behaviour.

Item 1 has one deliberate behaviour change: "-1" into a UInt64 column currently writes 18446744073709551615 and would now throw NumberFormatException. That replaces silent corruption with a loud error and aligns the String path with the existing BigInteger overload. Suggest keeping it as its own commit so it can be reviewed separately from the additive branches.

The Long / Number path stays permissive and passes raw bits through unchanged — callers legitimately supply the bit pattern for values above 2^63.

Why it matters

Reported from the ClickHouse Flink connector. Its checkpoint state format serialises map keys as strings, so for a Map(K, V) column the key reaches serializeMapData (:478) → serializePrimitiveData as a String. The connector currently has to reject Map(UInt64, …), Map(UUID, …), Map(Date, …), Map(Date32, …) and Map(DateTime(64), …) at planning time and tell users to change their table DDL, even though all of these are legal ClickHouse map key types.

More generally, any caller passing a String value for one of these types — nested or top-level — hits the same behaviour.

Lenguaje dominante
Java
Estrellas
1.6k
Forks
637
Merge medio
3 d 8 h
PR fusionados (30 d)
32

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ClickHouse/clickhouse-java

Todos los issues de ClickHouse/clickhouse-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.