Workflow [PR], commit [aca7466]

AI Review

Summary

This PR hardens SerializationReplicated against one malformed REPLICATED native-TCP payload shape by validating each replicated index before attaching it, and the new raw-protocol regression covers that specific out-of-range-index case. I found one remaining blocker: the deserializer still trusts the advertised nested element count and never verifies that the nested subcolumn actually read that many rows, so a truncated payload can still leave ColumnReplicated with valid-looking indexes that point past the real nested data.

Findings

❌ Blockers

• [src/DataTypes/Serializations/SerializationReplicated.cpp:292] SerializationReplicated now validates indexes against the declared num_elements, but it still never checks that nested->deserializeBinaryBulkWithMultipleStreams produced num_elements rows. Primitive bulk readers such as SerializationNumber::deserializeBinaryBulk short-read on EOF instead of throwing, and NativeReader::readData only validates the top-level column->size(); for ColumnReplicated that is just the index count. A client can therefore send in-range indexes, claim num_elements = N, truncate the elements payload, and still hand an invalid ColumnReplicated to the insert pipeline, preserving the out-of-bounds read on later materialization. Suggested fix: after nested deserialization, verify column_replicated.getNestedColumn()->size() == num_elements and throw INCORRECT_DATA on mismatch before returning.

Tests

• ⚠️ Add a regression for the truncated-elements case: advertise num_elements > actual_nested_values, keep all indexes < num_elements, and end the payload after the short nested data. The current new test only exercises out-of-range indexes, not the still-accepted short-read path.

Final Verdict

Changes requested.