SEPURI-SAI-KRISHNA commented on issue #12988: URL: https://github.com/apache/seatunnel/issues/12988#issuecomment-6554956755
I would like to pick this up. I checked the gap on current `dev` (fcb404cd94) against a real Elasticsearch 9.5.5 in Docker, running SeaTunnel jobs on the Zeta engine. The gap reproduces without any reporter-specific setup: - **Only the sink is blocked.** `ElasticsearchVersion` stops at 8, and the sink parses the cluster version when the writer starts, so the job fails with `ErrorCode:[ELASTICSEARCH-02] ... version=9,fail fo find ElasticsearchVersion`. The source and the catalog never parse the version. - **The source already works on 9.5.5.** Scroll, PIT with `slice_max = 2`, and SQL search all return the right rows, and `dense_vector` fields come back too. - **Two 9.x breaking changes could have mattered, and neither does.** The stricter bulk action parsing in 9.0 accepts every action line the sink writes (index, update with `doc_as_upsert`, delete). The 9.2 default that leaves vectors out of `_source` does not hide them here, because the scroll and PIT searches always send an explicit `_source` field list, and Elasticsearch then returns the vector. With an `ES9` entry added, the same jobs pass end to end: insert, update and delete by primary key, `DROP_DATA` on an existing index, and reading the result back with all three search APIs. The change is small: the enum value, a unit test, a dedicated `Elasticsearch9IT` on `elasticsearch:9.5.5` (the existing ITs stay on 8.9.0), and the supported range in the EN and ZH docs. I will open the PR and link it here. -- 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]
