apache/cassandra · error · MarshalException

Unable to make long from '%s'

Error message

Unable to make long from '%s'

What it means

LongType.fromString parses a string as a signed 64-bit long (Long.parseLong). Any non-numeric string or a value outside Long.MIN_VALUE..Long.MAX_VALUE causes parseLong to throw, which is wrapped in a MarshalException with this message.

Source

Thrown at src/java/org/apache/cassandra/db/marshal/LongType.java:111

        else
            return accessor.valueOf(ByteSourceInverse.getVariableLengthInteger(comparableBytes));
    }

    public ByteBuffer fromString(String source) throws MarshalException
    {
        // Return an empty ByteBuffer for an empty string.
        if (source.isEmpty())
            return ByteBufferUtil.EMPTY_BYTE_BUFFER;

        long longType;

        try
        {
            longType = Long.parseLong(source);
        }
        catch (Exception e)
        {
            throw new MarshalException(String.format("Unable to make long from '%s'", source), e);
        }

        return decompose(longType);
    }

    @Override
    public Term fromJSONObject(Object parsed) throws MarshalException
    {
        try
        {
            if (parsed instanceof String)
                return new Constants.Value(fromString((String) parsed));

            Number parsedNumber = (Number) parsed;
            if (!(parsedNumber instanceof Integer || parsedNumber instanceof Long))
                throw new MarshalException(String.format("Expected a bigint value, but got a %s: %s", parsed.getClass().getSimpleName(), parsed));

            return new Constants.Value(getSerializer().serialize(parsedNumber.longValue()));

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Supply a valid integer literal within the 64-bit range, e.g. '123' not '1.5'.
  2. If the value exceeds long range, change the column type to varint or decimal.
  3. Strip formatting (commas, spaces) and parse/validate in the client before sending.

Example fix

// before
INSERT INTO t (n) VALUES ('1,000,000');
// after
INSERT INTO t (n) VALUES ('1000000');
Defensive patterns

Strategy: try-catch

Validate before calling

try { Long.parseLong(source.trim()); } catch (NumberFormatException e) { throw new IllegalArgumentException("Not a 64-bit integer: " + source); }

Type guard

boolean isValidLong(String s) { try { Long.parseLong(s.trim()); return true; } catch (Exception e) { return false; } }

Try / catch

try { term = LongType.instance.fromString(source); } catch (MarshalException e) { throw new BadRequestException("bigint column requires a 64-bit integer: " + source); }

Prevention

When it happens

Trigger: Inserting/updating a bigint column with a string literal that is not a valid long: text, empty string, decimal like '1.5', or a number exceeding 64-bit range (e.g. values larger than 9223372036854775807).

Common situations: Users inserting values meant for a varint/decimal column into a bigint column; JavaScript numbers losing precision or arriving as strings; locale-formatted numbers with thousand separators.

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