alibaba/canal · error · IllegalArgumentException

The provided data type doesn't map to know any known one.

Error message

The provided data type doesn't map to know any known one.

What it means

Thrown by KuduTemplate.toKuduType() when a MySQL column type string is not one of the handful handled by the switch: varchar, int, decimal, double, datetime, timestamp. Any other type (e.g. bigint, text, tinyint, date, float, char, json) hits the default and aborts. This is a hard limitation of the kudu adapter's type mapping, not a transient failure.

Source

Thrown at client-adapter/kudu/src/main/java/com/alibaba/otter/canal/client/adapter/kudu/support/KuduTemplate.java:421

     * @param
     */
    private Type toKuduType(String mysqlType) throws IllegalArgumentException {

        switch (mysqlType) {
            case "varchar":
                return Type.STRING;
            case "int":
                return Type.INT8;
            case "decimal":
                return Type.DOUBLE;
            case "double":
                return Type.DOUBLE;
            case "datetime":
                return Type.STRING;
            case "timestamp":
                return Type.STRING;
            default:
                throw new IllegalArgumentException("The provided data type doesn't map to know any known one.");
        }
    }
}

View on GitHub (pinned to 87be50e876)

Solutions

Avoid unsupported column types in tables synced to kudu, or exclude them via targetColumns so they are not written.
If you control the code, extend toKuduType() with additional cases (e.g. 'bigint' -> Type.INT64, 'text'/'char' -> Type.STRING) and rebuild the kudu adapter module.
Pre-convert the source column to a supported type (e.g. varchar).

Example fix

// before: only 6 types handled, everything else throws
// after: extend the switch
case "bigint":
    return Type.INT64;
case "text":
case "char":
    return Type.STRING;
case "float":
    return Type.FLOAT;

Defensive patterns

Strategy: validation

Validate before calling

// Before syncing, check every source column type is one KuduTemplate can map.
Set<String> supported = Set.of("varchar","int","decimal","double","datetime","timestamp");
for (Map.Entry<String,String> e : columnTypes.entrySet()) {
    if (!supported.contains(e.getValue().toLowerCase())) {
        throw new IllegalStateException(
            "Column " + e.getKey() + " has unsupported type " + e.getValue()
            + " for kudu; convert it or exclude it via targetColumns");
    }
}

Prevention

Audit source schemas for types outside {varchar,int,decimal,double,datetime,timestamp} before pointing kudu sync at them.
Extend toKuduType() with the cases your schemas need and add a unit test per case.
Use targetColumns to exclude columns whose types the adapter cannot map.

When it happens

Trigger: KuduSyncService/KuduTemplate processes a DML whose column type, read from the canal message, is not in the switch's case list; toKuduType() reaches the default branch.

Common situations: A source table contains a column type the adapter never mapped (bigint is the most common, since only 'int' -> INT8 is handled). A schema change adds such a column and the next sync fails. Note also that 'int' maps to INT8 (a byte), so integer ranges may already be lossy.

Related errors

AI-assisted analysis of alibaba/canal@87be50e876 (2026-08-14). Data as JSON: /api/errors/81bc579efe65df8e. Report an issue: GitHub.