ranflarion opened a new pull request, #10497:
URL: https://github.com/apache/arrow-rs/pull/10497
# Which issue does this PR close?
- Closes #10494.
- Closes #10495.
# Rationale for this change
Both `BlockDecoder` and `HeaderDecoder` assemble the 16-byte sync marker
with an offset derived from the size of the incoming fragment (`sync[16 -
to_decode..]`), which only works when all 16 bytes arrive in one `decode()`
call; a marker straddling a chunk boundary gets scrambled (#10494). For
`HeaderDecoder` this is live today: a header larger than one fetch whose
trailing marker straddles the boundary yields a garbled `Header::sync()`, the
async reader's sync marker scan never matches, and a valid file silently reads
as an empty stream.
With assembly fixed, `Block.sync` becomes trustworthy, enabling the
validation the Avro spec intends the marker for: both readers now compare each
block's trailing marker against the file header's and reject a mismatch,
matching the Java reference reader (`DataFileStream` throws `Invalid sync!`)
(#10495). This continues the recent hardening of the container decode path
(#10237, #10407). Without it, a desynced or corrupted stream can decode
silently into wrong values; avro-deflate block data is raw DEFLATE with no
checksum, so this is a real silent-corruption window with transiently faulty
object stores.
# What changes are included in this PR?
- `BlockDecoder` and `HeaderDecoder` fill the sync marker from the front
using the consumed count (`offset = 16 - bytes_remaining`).
- The sync `Reader` and the async reader error with `ParseError("Avro block
sync marker does not match file header")` when a flushed block's marker differs
from the header's.
# Are these changes tested?
- A `BlockDecoder` unit test feeds a block in every chunk size from 1 byte
up and asserts the assembled marker; it fails on main.
- Both readers get a test that flips the final byte of `alltypes_plain.avro`
(the last block's sync marker) and asserts the read fails; on main the flip is
accepted silently.
- Existing suites pass unchanged, including the roundtrip and range-read
tests.
# Are there any user-facing changes?
Corrupt files that previously decoded silently (or, for the header case,
silently produced an empty stream) now error, matching the Java reader.
Appended files reuse the file's marker, so any file the reference reader
accepts still reads fine.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
