SEZ9 commented on PR #11557: URL: https://github.com/apache/seatunnel/pull/11557#issuecomment-6008751359
Thanks for the detailed follow-up on F1 and for the changes in `5a0f93b37de`. The new approach in `ManagedSourceRegisterOperation#readInternal` — decoding via the wire `factoryId`/`classId` and rejecting anything that is not a `TaskLocation` (including `null`) with an explicit `IOException` before any use — is the right shape, and I agree that relying on the public `ObjectDataInput` contract rather than Hazelcast's internal header layout is the more robust choice. The test coverage also looks appropriate: `testMismatchedReaderLocationTypeIsRejected` targeting a `Progress` in the reader-location slot (same factory id, different class id) is exactly the case that the previous `readObject(TaskLocation.class)` override would have read positionally, and the byte-for-byte round-trip assertion guards against regressions on the happy path. Remaining asks before I resolve F1: 1. Since the tests have not been run locally, please confirm once the new head has completed CI that `ManagedSourceRegisterOperationSerializationTest` passes, and share the result here. 2. On the pre-existing untyped `taskID = in.readObject()` in `AssignSplitOperation#readInternal` and the `readObject(TaskLocation.class)` in the base `TaskOperation#readInternal`: I'm fine keeping those out of this PR since they are on `dev` and shared by legacy operations. Please open a follow-up issue tracking both so the same explicit wire-type check can be applied there, and link it in this thread so we don't lose the context from your Hazelcast analysis. Once CI is green on the new head and the follow-up is filed, I'll mark F1 as resolved. <!-- streview-comment:1551 --> -- 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]
