SEZ9 commented on PR #11479: URL: https://github.com/apache/seatunnel/pull/11479#issuecomment-5421603154
Thanks @DanielLeens — we're aligned on both points. F1: withdrawn, so there is no currently-marked blocker on this head. F2–F8: agreed, they remain open, unresolved asks. And your plan sounds right — since the head is unchanged, a fresh independent pass now wouldn't add much; we'll do the full joint pass on F2–F7 (plus the F5 Javadoc ask) once a new commit lands. To keep the concrete asks explicit for the author: - **F2**: trace the tikv-client-java key-decoding path (not a guess) to determine whether `RowKey.decode(...).getHandle()` throws on a short encoded key before the restore call in `SeaTunnelRowSnapshotRecordDeserializer` runs. - **F4**: add a length/type guard in `restorePrimaryKeyColumns` before the fixed `skipBytes(11)`, so we don't blindly skip on keys that are too short or aren't common-handle keys. - **F3**: make the restore per-column rather than all-or-nothing, so key-decoded bytes don't overwrite PK values already present in the row value. - **F5**: add class-level Javadoc to `CommonHandleDecoder` and document what `RECORD_KEY_PREFIX_LENGTH = 11` represents. - **F6**: extend `CommonHandleDecoderTest` to cover a streaming UPDATE (PUT with non-empty oldValue) and a table where the guard must skip (pkHandle / non-clustered PK). - **F7**: null-check `TiTableInfo.getIndices()` in `primaryIndex()`. - **F8** (low): avoid the duplicate `ByteString.toByteArray()` copies and the per-record linear primary-index scan in the streaming deserializer. Once a new commit addresses these, ping me and we'll do the combined verification pass as planned. Thanks for keeping this organized! <!-- streview-comment:566 --> -- 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]
