fix: avoid panic when repdef serializes empty offsets

[fenfeng9]

Fixes panic on empty list offsets ([0]).

The assertion expected_len - 1 underflows when expected_len == 0. We early-return because zero values produce no rep/def levels.

[fenfeng9]

PTAL @westonpace .

[westonpace]

This is a good fix for repdef, thanks! Did you run into this scenario with actual data? Or is it theoretical? I wonder if we had checks for empty arrays higher in the code somewhere?

[fenfeng9]

This is a good fix for repdef, thanks! Did you run into this scenario with actual data? Or is it theoretical? I wonder if we had checks for empty arrays higher in the code somewhere?

You're right that FileWriter::write_batch does check for empty batches and returns early

lance/rust/lance-file/src/writer.rs

Lines 385 to 397 in 556851b

	pub async fn write_batch(&mut self, batch: &RecordBatch) -> Result<()> {
	debug!(
	"write_batch called with {} rows, {} columns, and {} bytes of data",
	batch.num_rows(),
	batch.num_columns(),
	batch.get_array_memory_size()
	);
	self.ensure_initialized(batch)?;
	self.verify_nullability_constraints(batch)?;
	let num_rows = batch.num_rows() as u64;
	if num_rows == 0 {
	return Ok(());
	}

The panic I encountered was triggered through the encode_batch function

lance/rust/lance-encoding/src/encoder.rs

Lines 689 to 698 in 556851b

	/// Helper method to encode a batch of data into memory
	///
	/// This is primarily for testing and benchmarking but could be useful in other
	/// niche situations like IPC.
	pub async fn encode_batch(
	batch: &RecordBatch,
	schema: Arc<Schema>,
	encoding_strategy: &dyn FieldEncodingStrategy,
	options: &EncodingOptions,
	) -> Result<EncodedBatch> {

[fenfeng9]

This is a good fix for repdef, thanks! Did you run into this scenario with actual data? Or is it theoretical? I wonder if we had checks for empty arrays higher in the code somewhere?

Inspired by issue #5141 regarding fuzz testing for the file format, I wrote a simple local fuzzer. This panic occurred while generating seed files.

[fenfeng9]

BTW, could you help review this PR #5867 when you have a moment?