[Testing] Test downstream plugins that load SQL classes (alerting, skills)

Đang mở
  • Có gì không ổn?
#5,925 1 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ahkcs đang làm issue này rồi.

Từ ngày 3/11/2026.

  • #5926 của @ig-suyas — đang mở

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
18/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
testing-qa

Hướng nghiên cứu

Start with ThinJarClassesTest and the thin-jar build for the SQL plugin, then read PPLQueryAction, TransportPPLQueryRequest, TransportPPLQueryResponse and PPLQueryTask to see what consumers load. The work is a CI task that installs alerting with a rebuilt thin jar and runs a PPL monitor, plus an isolated classloader check that fails on LinkageError. Done means both checks run in CI and would have caught the NoClassDefFoundError in #5923.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

infrastructure testing
Problem

Our unit and integration tests check that SQL/PPL works on its own. They don't check the plugins that load SQL classes directly, so a change can pass all of our CI and still break them.

That happened in 3.10.0: #5910 added an opensearch-module interface to PPLQueryTask. All SQL CI passed, but every PPL alerting monitor crashed the node with NoClassDefFoundError (#5923, fixed in #5924). It was found in Observability stack testing, near code freeze.

Why our tests miss this
  • Alerting and skills call PPLQueryAction using their own opensearch-sql-thin jar. They build it from our plugin classes plus the core, ppl, and protocol jars, and it does not include the opensearch module. Their classloader therefore sees only part of our code.
  • Our ITs run with the whole SQL plugin on one classpath, so a class that is fine for us but broken for them always passes.
  • #5924 added ThinJarClassesTest. It only checks the four classes we know alerting loads, by reflection, so it would miss a new class or a new consumer.
Proposal
  1. Consumer smoke IT. Add a CI task that installs alerting (and skills, if practical) with its thin jar rebuilt from the current SQL build, then runs a PPL monitor create, an _execute, and a scheduled run, and checks that the node stays up. This would have caught #5923 before merge.
  2. Isolated classloader check. Build a thin jar the way alerting does. Load the consumer-facing classes in a classloader that holds only that jar plus core/ppl/protocol and OpenSearch, and fail on any LinkageError. This is stricter than the reflection check in ThinJarClassesTest.
  3. Document the consumer surface. List the classes other plugins load: PPLQueryAction, TransportPPLQueryRequest, TransportPPLQueryResponse, PPLQueryTask, and any classes skills uses. Treat them as API, and note in the developer docs that they must not depend on the opensearch module.
  4. Find all consumers. Check which other plugins (alerting, skills, query-insights, others) bundle SQL classes, so the tests above cover all of them.
Related
  • #5923 / #5924: the regression and the fix
  • opensearch-project/alerting#2322: alerting CI failed on the same regression
Ngôn ngữ chính
Java
Star
175
Fork
236
Merge trung bình
3 ngày 36 phút
Pull request đã merge (30 ngày)
41

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của opensearch-project/sql

Tất cả issue của opensearch-project/sql

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.