[GH] (fluss/codex/arrow-batch-commit-timestamp-single): Workflow run "Client Integration" failed!

[GitBox <gi...@apache.org>]

The GitHub Actions job "Client Integration" on fluss.git/codex/arrow-batch-commit-timestamp-single has failed.
Run started by GitHub user spoon-lz (triggered by spoon-lz).

Head commit for run:
fc860297ae0486cf8037610550ce7ace657b6720 / liuzhuo <li...@xiaohongshu.com>
[rust] Expose Arrow batch commit timestamps in client bindings

The record-level scan API already reports the commit timestamp the leader
assigned to a log batch, but the Arrow batch APIs dropped it while decoding,
so batch consumers had no way to tell when a batch was written without
falling back to per-record iteration.

Carry the timestamp from `LogRecordBatch` through the fetch path onto
`ScanBatch`, and surface it as `ScanBatch::commit_timestamp`,
`RecordBatch.commit_timestamp` (Python) and
`ArrowRecordBatch::GetCommitTimestamp` (C++). Slicing a batch to a
subscription offset or to a bounded-read stop offset keeps the timestamp of
the log batch it came from.

A limit scan concatenates several log batches into one Arrow batch and
therefore has no single commit timestamp; it reports the
`NO_COMMIT_TIMESTAMP` sentinel (-1), matching the sentinel `ScanRecord`
already uses for an unknown timestamp.

The integration tests verify the batch path against the record path rather
than against the wall clock: both read the same header field off the same log
batch, so they must agree for every offset a batch covers. That comparison is
exact and clock-independent, and it catches a batch handed another log batch's
timestamp, which a "looks like a recent timestamp" bound cannot.

Report URL: https://github.com/apache/fluss/actions/runs/37922546974

With regards,
GitHub Actions via GitBox