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
- Check that every column's element count equals the StreamChunk cardinality and that visibility/null-bitmap arrays have the same length
- Validate Java-side values fit the declared column types before calling the binding
- Regenerate schema definitions if columns were altered on one side only
- 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
- Assert all column arrays share the chunk cardinality
- Match Java value types to declared column physical types (no i64 into i32)
- Keep null-bitmap/visibility lengths equal to row count
- Regenerate schema code after column changes
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)