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

  1. 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
  2. If seen in tests, fix the mock/stub to return a realistic ContentEncoding/size value
  3. 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
  4. 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

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


AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/bad698374f1dc788. Report an issue: GitHub.