[Bug] AdminSendMessage keeps only the first system property key, dropping the rest

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

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

@Felix-Gong đang làm issue này rồi.

Từ ngày 20/10/2026.

  • #11469 của @Felix-Gong — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
java
Lĩnh vực
backend-api-design

Hướng nghiên cứu

Start in ProxyAdminGrpcService.buildAdminMessage and compare its handling of AdminSendMessageRequest.system_properties.keys with SendMessageActivity and the existing adminSendMessageCarriesTagsKeysAndPropertiesTest in ProxyAdminGrpcServiceTest. Extend the test to cover multiple non-empty keys, empty entries, and precedence over the singular key, then run that test on the repository's supported JDK. Done means all non-empty repeated keys are space-joined and the existing singular-key behavior remains covered.

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

Mô tả

Search before asking

I checked open and closed issues and PRs for AdminSendMessage, system_properties.keys, buildAdminMessage and setKeys. The open work on this class (#11356 / PR #11357 on message-group queue selection, #11406 on retry-topic ACL) does not touch the message-key path, and no existing report covers the repeated keys field.

What happened?

AdminSendMessageRequest.system_properties.keys is a repeated field, and the data plane keeps every entry: SendMessageActivity validates each key and calls Message.setKeys(Collection), which joins the list. The admin surface does not. ProxyAdminGrpcService.buildAdminMessage reads the same field but keeps only the first non-empty entry:

for (String key : systemProperties.getKeysList()) {
    if (!key.isEmpty()) {
        message.setKeys(key);
        break;
    }
}

Send a message through AdminSendMessage with system_properties.keys = ["k1", "k2", "k3"] and the stored message carries only k1. The RPC answers OK with a message id, so nothing tells the caller that two index keys vanished. Messages keyed this way are then only findable by k1 in key-based queries, which is the whole point of sending keys.

The singular key field still works (covered by the existing adminSendMessageCarriesTagsKeysAndPropertiesTest); only the repeated system_properties.keys path is lossy.

Runtime

develop at 57c2dc0, Temurin 11 (the pinned surefire/ByteBuddy stack does not run on JDK 21). Reproduced with the existing ProxyAdminGrpcServiceTest mocks — no broker needed. On the unpatched service, the new test fails with:

expected:<key1[ key2 key3]> but was:<key1[]>
Expected behavior

Every non-empty entry of system_properties.keys ends up on the message, space-joined like the data plane does. Empty entries are skipped. Precedence stays as it is today: a non-empty system_properties.keys overrides the singular key; an all-empty list leaves the singular key in place.

Ngôn ngữ chính
Java
Star
22.7k
Fork
12k
Merge trung bình
3 ngày 18 giờ
Pull request đã merge (30 ngày)
17

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 apache/rocketmq

Tất cả issue của apache/rocketmq

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.