What causes "Cannot parse 32-bits int value from "%s"" in apache/cassandra?

Validate the string is a signed 32-bit integer before calling parse (e.g. Long/Integer.parseInt in a try block, or regex ^-?\d{1,10}$ plus range check).

apache/cassandra · error · InvalidTypeException

Cannot parse 32-bits int value from "%s"

Error message

Cannot parse 32-bits int value from "%s"

What it means

Thrown by TypeCodec.IntCodec.parse(String) when a string literal intended for a CQL int (32-bit) column cannot be parsed by Integer.parseInt, i.e. it is not a valid signed 32-bit integer literal. The library wraps the NumberFormatException in InvalidTypeException because the value violates the CQL int literal grammar. Callers are typically building query strings or simple statements via codec.parse().

Source

Thrown at src/java/org/apache/cassandra/cql3/functions/types/TypeCodec.java:1682

        @Override
        public int serializedSize()
        {
            return 4;
        }

        @Override
        public Integer parse(String value)
        {
            try
            {
                return value == null || value.isEmpty() || value.equalsIgnoreCase("NULL")
                       ? null
                       : Integer.parseInt(value);
            }
            catch (NumberFormatException e)
            {
                throw new InvalidTypeException(
                String.format("Cannot parse 32-bits int value from \"%s\"", value));
            }
        }

        @Override
        public String format(Integer value)
        {
            if (value == null) return "NULL";
            return Integer.toString(value);
        }

        @Override
        public ByteBuffer serializeNoBoxing(int value, ProtocolVersion protocolVersion)
        {
            ByteBuffer bb = ByteBuffer.allocate(4);
            bb.putInt(0, value);
            return bb;
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Validate the string is a signed 32-bit integer before calling parse (e.g. Long/Integer.parseInt in a try block, or regex ^-?\d{1,10}$ plus range check).
Fix the source data: strip whitespace, remove thousands separators, or correct the literal.
If the value can exceed int range, change the CQL column to bigint/varint and use the matching codec.
Catch InvalidTypeException at the statement-building boundary and surface a user-facing validation message.

Example fix

// before
Integer n = TypeCodec.cint().parse(userInput);
// after
String cleaned = userInput == null ? null : userInput.trim();
Integer n;
try { n = cleaned == null ? null : Integer.parseInt(cleaned); }
catch (NumberFormatException e) { throw new IllegalArgumentException("Expected a 32-bit int, got: " + userInput, e); }

Defensive patterns

Strategy: validation

Validate before calling

static boolean isCqlInt(String s) {
    if (s == null) return false;
    String t = s.trim();
    if (!t.matches("-?\\d+")) return false;
    try { Integer.parseInt(t); return true; } catch (NumberFormatException e) { return false; }
}

Try / catch

try {
    Integer v = TypeCodec.cint().parse(raw);
} catch (InvalidTypeException e) {
    log.warn("Bad int literal: {}", e.getMessage());
    throw new BadRequest("Expected a 32-bit integer");
}

Prevention

Never concatenate raw user input into CQL literals; validate numerics first.
Prefer bound statements with typed parameters over string parsing.
Trim and normalize numeric strings (remove separators/spaces) before parsing.
Check the column type matches the codec (int vs bigint vs varint).

When it happens

Trigger: Calling IntCodec.parse() with a non-numeric string (e.g. "12a"), a decimal ("3.14"), an empty-after-unquoting token, or an out-of-int-range literal like "3000000000"; the codec maps DataType.cint() so any parse path for cint literals funnels here.

Common situations: Hand-building INSERT/UPDATE literals where user input is concatenated unvalidated; reading values from config/CSV/JSON that were assumed numeric; locale-formatted numbers containing spaces or separators; pasting a bigint or float literal into an int column.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/01328b2435dd0916. Report an issue: GitHub.