apache/cassandra · error · InvalidTypeException

Cannot parse 64-bits long value from "%s"

Error message

Cannot parse 64-bits long value from "%s"

What it means

The bigint codec's parse() delegates to Long.parseLong, and any string that is not a valid signed 64-bit decimal (empty handled earlier, but garbage, overflow, or wrong type) raises NumberFormatException, which is translated into InvalidTypeException. It exists to give a codec-specific message instead of the raw JDK exception.

Source

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

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

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

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

        @Override
        public ByteBuffer serializeNoBoxing(long value, ProtocolVersion protocolVersion)
        {
            ByteBuffer bb = ByteBuffer.allocate(8);
            bb.putLong(0, value);
            return bb;
        }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Pass a plain base-10 integer string that fits in a signed 64-bit range (−9223372036854775808..9223372036854775807).
  2. Round/truncate or use the decimal codec if the value legitimately has a fractional part.
  3. Trim whitespace and strip separators before parsing.
  4. If the value overflows 64 bits, change the column to varint (bigInteger codec) or store as text.

Example fix

// before
longCodec.parse("1.5"); // throws
// after
longCodec.parse(String.valueOf((long) Double.parseDouble("1.5"))); // "1"
Defensive patterns

Strategy: validation

Validate before calling

static boolean isCqlBigintLiteral(String v) {
    if (v == null) return false;
    try { Long.parseLong(v.trim()); return true; }
    catch (NumberFormatException e) { return false; }
}

Type guard

boolean isLongLiteral(String v) {
    return v != null && v.trim().matches("^[+-]?\\d{1,19}$");
}

Try / catch

try {
    return longCodec.parse(raw);
} catch (InvalidTypeException e) {
    throw new IllegalArgumentException("Not a 64-bit integer literal: " + raw, e);
}

Prevention

When it happens

Trigger: Calling bigintCodec.parse(value) where value is e.g. "1.5", "9223372036854775808" (Long.MAX_VALUE+1), "0x10", "12abc", or contains whitespace/underscores.

Common situations: Parsing values read from CSV/JSON imports where a float or formatted number lands in a bigint column; locale-formatted numbers with thousand separators; hex or scientific notation pasted into CQL literals; overflow from counters generated in another system.

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/6638b38f6863999c. Report an issue: GitHub.