DanielLeens commented on PR #11559: URL: https://github.com/apache/seatunnel/pull/11559#issuecomment-5421792656
@SEZ9 Thanks for the quick turnaround. On your three points: 1. **Shaded HOCON separator** — agreed, and thanks for confirming the root cause independently. That's the most consequential miss across this whole review, so a hand-built config object clearly isn't sufficient test coverage going forward — routing the new regression test through the real shaded parser is the right fix. I'll wait for that commit before re-deriving anything. 2. **`kafka-connector-it (8, ubuntu-latest)` diagnosis, un-truncated** — apologies for whatever cut it off in rendering. Full paragraph from round 14, verbatim: "This PR does touch `KafkaSourceReader` on the normal path, so I traced it rather than waving it off. The added `synchronized (gateLock)` blocks (`:144`, `:187`, `:200`) are entered only by the source task thread in a non-gated job, so they are uncontended and cannot deadlock or stall; `pollNext` adds one volatile read; `copySplits` adds allocation but no blocking. Meanwhile the failing test class ran for 8,496 s in that job and the failure is the well-known `awaitStreamingPipelineReady` readiness timeout under runner load. I'm calling it environmental — but it must be re-confirmed on a rebased head, because this branch is 140 commits behind `dev` and that is by far the largest drift of any open PR I'm looking at right now." So: environmental on this head, but the call is provisional on the rebase — please re-run `ka fka-connector-it` after syncing `dev` rather than trusting this read on the stale head. 3. **`KafkaSourceReader` deserialization** — I re-checked this specific spot against the current head (`76611dfa15`) before replying, since your note conflicts with what round 14 found. `KafkaSourceReader.java:418-444` (`KafkaGateObjectInputStream.resolveClass` / `isAllowedClass`) already restricts restored gate-split objects to an explicit allowlist of exact class names — `[B`, `java.lang.String`, `java.lang.Long`, `java.lang.Integer`, `KafkaSourceSplit`, `TopicPartition`, `TablePath` — and throws `IOException` on anything else. This is tighter than the other two `*ObjectInputStream` sites (which use package-prefix allowlists and still have the residual container-class breadth I flagged as Low); this one is a closed enum of exact names, so on my read it's already fixed, not open. Could you point me to the exact line or a second `readObject()` call you're still seeing as unguarded in this file? I don't want to talk past you if there's something I'm missing. Once the HOCON-separator fix and the rebase are up, I'll run the full round-15 pass on the fresh head. -- 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]
