risingwavelabs/risingwave · error · BindingError::StreamChunkArray

StreamChunkArrayError

Error message

StreamChunkArrayError {error}

What it means

BindingError::StreamChunkArray wraps ArrayError from the RisingWave array library, raised while constructing or accessing typed arrays (I32Array, Utf8Array, etc.) that back a StreamChunk during JNI conversions. Shown as 'StreamChunkArrayError {error}'. It indicates the array data supplied from the Java side violates the array type invariants (wrong element count, invalid null bitmap, value out of the array's physical type).

Solutions

  1. Check that every column's element count equals the StreamChunk cardinality and that visibility/null-bitmap arrays have the same length
  2. Validate Java-side values fit the declared column types before calling the binding
  3. Regenerate schema definitions if columns were altered on one side only
  4. Enable the full report of the wrapped ArrayError in the thrown Java exception to see which array/offset failed

Example fix

// before
chunk = StreamChunk.of(values, visibility /* len 2 vs 3 values */); // StreamChunkArrayError
// after
assert values.length == visibility.length; // both cardinality 3
chunk = StreamChunk.of(values, visibility);
Defensive patterns

Strategy: validation

Validate before calling

// Java, before building a StreamChunk
if (values.length != cardinality || visibility.length != cardinality)
    throw new IllegalArgumentException("column/visibility length must equal cardinality");

Try / catch

try {
    chunk = StreamChunk.of(values, visibility);
} catch (RuntimeException e) {
    if (e.getMessage().contains("StreamChunkArrayError")) {
        // compare per-column lengths and types with declared schema
    }
    throw e;
}

Prevention

When it happens

Trigger: JNI entry points that build StreamChunks or columns from Java data where the number of elements doesn't match the chunk cardinality, a null-bitmap is inconsistent, or an integer/string value cannot be stored in the target array type.

Common situations: Java connector pushes rows whose column count mismatches the declared schema; inserting a value exceeding the target width (e.g. i64 into i32 column); mismatched visibilities/null masks length.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/51f0b1ade049b513. Report an issue: GitHub.

Appendix: source

Thrown at src/jni_core/src/lib.rs:105

        error: jni::errors::Error,
        backtrace: Backtrace,
    },

    #[error("StorageError {error}")]
    Storage {
        #[from]
        error: anyhow::Error,
        backtrace: Backtrace,
    },

    #[error("DecodeError {error}")]
    Decode {
        #[from]
        error: DecodeError,
        backtrace: Backtrace,
    },

    #[error("StreamChunkArrayError {error}")]
    StreamChunkArray {
        #[from]
        error: ArrayError,
        backtrace: Backtrace,
    },
}

type Result<T> = std::result::Result<T, BindingError>;

pub fn to_guarded_slice<'array, 'env>(
    array: &'array JByteArray<'env>,
    env: &'array mut JNIEnv<'env>,
) -> Result<SliceGuard<'env, 'array>> {
    unsafe {
        let array = env.get_array_elements(array, ReleaseMode::NoCopyBack)?;
        let slice = from_raw_parts(array.as_ptr() as *mut u8, array.len());

        Ok(SliceGuard {

View on GitHub (pinned to 6469eb736d)