DanielLeens commented on issue #12765: URL: https://github.com/apache/seatunnel/issues/12765#issuecomment-6191893915
Thank you for adding the configuration and the complete underlying failure. This is no longer a plugin-discovery problem: the connector is found and starts creating the source, then the ClickHouse client fails while creating the HTTP stream response. I checked the current connector path as well. The configured `host:port` is built as a ClickHouse **HTTP** node, and the project documentation also uses port 8123. The connector currently pins the ClickHouse Java client at `0.3.2-patch11`, so changing this job to the native port would not be a justified workaround. The `Magic is not correct` response establishes a protocol-level incompatibility or an intermediary response, but it does not yet distinguish the two. Before we call this a connector defect, please add sanitized results from the same SeaTunnel worker for: 1. `GET /ping` and a minimal `SELECT 1` over the HTTP endpoint, including only status code and response headers/body shape (no private address, credentials, or tokens). 2. Whether the endpoint is direct ClickHouse or passes through a proxy/load balancer, and whether any HTTP compression/TLS/rewriting policy is enabled. 3. The server revision/build details and the result of the same minimal job against a known working ClickHouse deployment, if one is available. That will tell us whether the old embedded client needs a compatibility fix for the 26.9 server response or whether the worker is receiving a non-ClickHouse HTTP response. No matching open compatibility PR was found, so a reproducible result here will provide the correct boundary for one. -- 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]
