apache/druid · warning
The object [%s, %s] has a size [%s] out of the range of the
Error message
The object [%s, %s] has a size [%s] out of the range of the long type. The max long value will be used for its size instead.
What it means
GoogleCloudStorageInputSource.getSize() logs this warning when a GCS object's reported size overflows a Java long when converted (Google may report sizes via BigInteger). Instead of propagating the overflow, the code catches ArithmeticException and falls back to Long.MAX_VALUE so partitioning logic still works. It is a degraded-accuracy warning, not a thrown error.
Source
Thrown at extensions-core/google-extensions/src/main/java/org/apache/druid/data/input/google/GoogleCloudStorageInputSource.java:160
return getSize(storageObject);
}
}
return new SplitWidget();
}
private static long getSize(final GoogleStorageObjectMetadata object)
{
final Long sizeInLong = object.getSize();
if (sizeInLong == null) {
return Long.MAX_VALUE;
} else {
try {
return sizeInLong;
}
catch (ArithmeticException e) {
LOG.warn(
e,
"The object [%s, %s] has a size [%s] out of the range of the long type. "
+ "The max long value will be used for its size instead.",
object.getBucket(),
object.getName(),
sizeInLong
);
return Long.MAX_VALUE;
}
}
}
@Override
public String toString()
{
return "GoogleCloudStorageInputSource{" +
"uris=" + getUris() +
", prefixes=" + getPrefixes() +View on GitHub (pinned to 9b90983fd2)
Solutions
- Verify the object's actual metadata (size) via gsutil/gcloud storage ls -l; real GCS objects fit in a long, so a bogus size means bad metadata
- If seen in tests, fix the mock/stub to return a realistic ContentEncoding/size value
- If the warning is noise in a real deployment, update the Google Cloud Storage client library so sizes arrive as long directly and the ArithmeticException path disappears
- No action needed functionally: code already uses Long.MAX_VALUE, and Druid treats it as an unpartitionable huge object
Example fix
// before
try {
return sizeInLong;
}
catch (ArithmeticException e) { LOG.warn(...); return Long.MAX_VALUE; }
// after
final BigInteger size = object.getSize();
if (size.compareTo(BigInteger.valueOf(Long.MAX_VALUE)) > 0) {
LOG.warn("Object [%s/%s] size [%s] exceeds long range; using Long.MAX_VALUE", object.getBucket(), object.getName(), size);
return Long.MAX_VALUE;
}
return size.longValue(); Defensive patterns
Strategy: validation
Validate before calling
if (object.getSize() == null || object.getSize().compareTo(BigInteger.valueOf(Long.MAX_VALUE)) > 0) {
// treat as unbounded size
} Type guard
static boolean fitsInLong(BigInteger size) { return size != null && size.bitLength() <= 63; } Prevention
- Use a recent Google Cloud Storage client library where sizes are long-typed
- Treat Long.MAX_VALUE sizes as 'unknown' in partitioning logic
- Add tests that stub realistic object sizes
When it happens
Trigger: Calling getSize() on an object whose size, when narrowed from BigInteger to long via longValueExact(), exceeds Long.MAX_VALUE (objects larger than ~9.2 exabytes)
Common situations: Effectively only possible with corrupted/hand-edited GCS metadata, mocked or proxied storage APIs reporting bogus sizes, or tests that stub objects with enormous sizes.
Understand the failure class
Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.
Related errors
- Specify exactly one of 'interval' and 'segments'
- Invalid input source specification
- Failed to remove output directory [%s] for segment pulled fr
- Emit called unexpectedly before service start
- unknown event type [%s]
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/bad698374f1dc788.
Report an issue: GitHub.