DanielLeens commented on PR #13009: URL: https://github.com/apache/seatunnel/pull/13009#issuecomment-6624231580
Thanks for the follow-up, @SiriusTL666, and for checking the default from the bytecode instead of trusting the earlier wording. I re-read the PR description: it now says `SocketClient` defaults `connectTimeout` to `0` in commons-net 3.6 and that this PR deliberately scopes itself to the control-channel read, and the testing section reports 31/31 with `SeaTunnelFTPFileSystemTimeoutTest` at 14. That closes Issue 1. The fork-run excerpt also resolves the one thing I could only infer last round: the `changes` job selected `connector-file-ftp-e2e`, and `FtpFileIT.testFtpControlTimeoutIsHonouredThroughTheJobConfig` actually executed in `updated-modules-integration-test-part-8` with no failures, so the distinct source (30000) and sink (15000) values went through factory validation and the real read/write path. Agreed on `assertOnlyControlTimeoutIsRejected` as well: pinning the exact single `control_timeout` error is the point, and a loud failure on a message-format change is the right trade-off. The head is still `5c268fe1`, the apache-side `Build` is green, and my approval stands. Merge still needs a committer approval under branch protection. Thanks again! -- 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]
