apache/druid · error · ExpressionValidationException

needs a LONG as its second argument but got null

Error message

needs a LONG as its second argument but got null

What it means

Thrown when HUMAN_READABLE_BYTES_FORMAT's optional second argument (precision) evaluates to SQL NULL. Because the precision must be a concrete LONG in [0,3], a null cannot be accepted and validation fails with this dedicated message.

Source

Thrown at processing/src/main/java/org/apache/druid/math/expr/Function.java:4690

      /**
       * only LONG and DOUBLE are allowed
       * For a DOUBLE, it will be cast to LONG before format
       */
      if (valueParam.value() != null && !valueParam.type().anyOf(ExprType.LONG, ExprType.DOUBLE)) {
        throw validationFailed(
            "needs a number as its first argument but got %s instead",
            valueParam.type()
        );
      }

      /**
       * By default, precision is 2
       */
      long precision = 2;
      if (args.size() > 1) {
        ExprEval precisionParam = args.get(1).eval(bindings);
        if (precisionParam.value() == null) {
          throw validationFailed("needs a LONG as its second argument but got null");
        }
        if (!precisionParam.type().is(ExprType.LONG)) {
          throw validationFailed("needs a LONG as its second argument but got %s instead", precisionParam.type());
        }
        precision = precisionParam.asLong();
        if (precision < 0 || precision > 3) {
          throw validationFailed("given precision[%d] must be in the range of [0,3]", precision);
        }
      }

      return ExprEval.ofString(HumanReadableBytes.format(valueParam.asLong(), precision, this.getUnitSystem()));
    }

    @Override
    public void validateArguments(List<Expr> args)
    {
      validationHelperCheckAnyOfArgumentCount(args, 1, 2);
    }

View on GitHub (pinned to 9b90983fd2)

Solutions

1. Use COALESCE(precision, 2) to supply the documented default of 2 when null.
2. Omit the second argument entirely so the built-in default (2) applies.
3. Filter out rows where the precision is NULL before applying the function.
4. Fix upstream data so the precision column is never null.

Example fix

// before
human_readable_bytes_format(b, prec_col) -- prec_col may be NULL
// after
human_readable_bytes_format(b, COALESCE(prec_col, 2))

COALESCE(precision_expr, 2) -- wrap nullable precision

if (precision == null) precision = 2;

try { runQuery(q); } catch (ExpressionValidationException e) { /* retry with default precision */ }

When it happens

Trigger: Calling human_readable_bytes_format(value, null) explicitly, or passing a nullable column/parameter whose value is NULL at evaluation time, e.g. human_readable_bytes_format(b, nullable_precision_col).

Common situations: Left-joined tables producing NULL precision columns; optional client parameters not supplied and defaulting to null; ETL writing nulls into the precision field.

Related errors

• first argument must be constant STRING expression containing
• first argument must be constant STRING expression containing
• needs a number as its first argument but got %s instead
• needs a LONG as its second argument but got %s instead
• given precision[%d] must be in the range of [0,3]

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