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
- Supply a valid integer literal within the 64-bit range, e.g. '123' not '1.5'.
- If the value exceeds long range, change the column type to varint or decimal.
- 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
- Validate numeric strings with Long.parseLong client-side before binding.
- Use varint/decimal columns for values that may exceed 64-bit range.
- Strip locale formatting (commas, spaces, signs) before parsing.
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
- Unable to make boolean from '%s'
- unable to make BigDecimal from '%s'
- unable to make UUID from '%s'
- Expected a bigint value, but got a %s: %s
- Unable to make short from '%s'
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/e2053d9c9ef9828c.
Report an issue: GitHub.