What causes "Array subscript out of bounds" in prestodb/presto?

Wrap index expressions in least(n, cardinality(arr)) or use a CASE to guard the subscript before calling element_at

prestodb/presto · error · InvalidFunctionArgumentException

Array subscript out of bounds

Error message

Array subscript out of bounds

What it means

ListSelectiveStreamReader throws InvalidFunctionArgumentException when it reads a position that was flagged as out of the array's bounds. This happens during selective list reading when a caller (e.g. the element_at function) requested an index beyond the number of elements in the list. The library deliberately surfaces invalid subscript usage as a function-argument error rather than silently returning null.

Source

Thrown at presto-orc/src/main/java/com/facebook/presto/orc/reader/ListSelectiveStreamReader.java:627

    @Override
    public void throwAnyError(int[] positions, int positionCount)
    {
        if (indexOutOfBounds == null) {
            return;
        }

        int positionIndex = 0;
        int nextPosition = positions[positionIndex];
        for (int i = 0; i < outputPositionCount; i++) {
            if (outputPositions[i] < nextPosition) {
                continue;
            }

            assert outputPositions[i] == nextPosition;

            if (indexOutOfBounds[i]) {
                throw new InvalidFunctionArgumentException("Array subscript out of bounds");
            }

            positionIndex++;
            if (positionIndex >= positionCount) {
                break;
            }

            nextPosition = positions[positionIndex];
        }
    }

    private void closeBlockLease(BlockLease elementBlockLease)
    {
        elementBlockLease.close();
        valuesInUse = false;
    }

    private void compactValues(int[] positions, int positionCount, boolean compactNulls)

View on GitHub (pinned to 55bb57d202)

Solutions

Wrap index expressions in least(n, cardinality(arr)) or use a CASE to guard the subscript before calling element_at
Fix the caller that computes output positions to never emit positions flagged in indexOutOfBounds
If this is a UDF author issue, validate index bounds inside the function and throw a PrestoException with INVALID_FUNCTION_ARGUMENT and a meaningful message
Check data for arrays whose declared/expected size differs from actual element count

Example fix

// before
SELECT element_at(arr, idx) FROM t;
// after
SELECT IF(idx <= cardinality(arr), element_at(arr, idx), NULL) FROM t;

Defensive patterns

Strategy: validation

Validate before calling

// SQL-side guard before subscripting
SELECT IF(idx BETWEEN 1 AND cardinality(arr), element_at(arr, idx), NULL) FROM t;

Try / catch

// UDF author side
try { ... } catch (InvalidFunctionArgumentException e) { throw new PrestoException(INVALID_FUNCTION_ARGUMENT, "array index out of bounds: " + idx); }

Prevention

Always bound-check dynamic array indexes against cardinality() in SQL
Never emit output positions beyond the array length when writing selective readers
Add tests for empty arrays and index = length boundary cases
Use COALESCE/IF to define behavior for out-of-range indexes instead of relying on exceptions

When it happens

Trigger: A query such as element_at(list_col, n) where n exceeds the array length and the position is marked in indexOutOfBounds during output position processing in getBlock/evaluate.

Common situations: Queries computing array indexes from data (e.g. index derived from another column or cardinality arithmetic) that can exceed array length for some rows; off-by-one logic in UDFs that build output positions.

Related errors

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/c3e465dc20aa7a81. Report an issue: GitHub.