[Bug] A cleared group forbidden state is persisted as the literal "null" and then fails the config load on the next broker start

Đang mở
  • Có gì không ổn?
#11,429 1 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

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

Từ ngày 14/10/2026.

  • #11430 của @iloveeyjafjalla — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
25/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, databases

Hướng nghiên cứu

Start in broker/src/main/java/org/apache/rocketmq/broker/config/v1/RocksDBSubscriptionGroupManager.java, where updateForbidden, setForbidden and clearForbidden write JSON.toJSONString of the group's table entry, and in decodeForbidden, which dereferences the parsed body. Run RocksDBSubscriptionGroupManagerTest to see the "null" write and the decode failure. Done means the cleared key is removed and a null body is skipped on load. Linked PR #11430 is already open, so check it before starting.

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

Mô tả

Before Creating the Bug Report
  • I found a bug, not just asking a question, which should be created in GitHub Discussions.
  • I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
  • I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment

OS: any (broker with the RocksDB config manager: enableRocksDBStore=true, i.e. RocksDBSubscriptionGroupManager)

RocketMQ version

branch: develop
Git commit id: a7edeecfb

JDK Version

Compiler: Temurin 1.8.0_504 (target 1.8, same as CI)

Describe the Bug

The RocksDB variant of the subscription group manager persists the group's forbidden bits with JSON.toJSONString(this.getForbiddenTable().get(group)), and after the last bit of a group is cleared the table no longer holds an entry for that group — so the value written to the forbidden column family is the string "null":

@Override
public void updateForbidden(String group, String topic, int forbiddenIndex, boolean setOrClear) {
    super.updateForbidden(group, topic, forbiddenIndex, setOrClear);
    this.rocksDBConfigManager.put(FORBIDDEN_COLUMN_FAMILY_NAME, group,
        JSON.toJSONString(this.getForbiddenTable().get(group)));   // -> "null" once the group has no forbidden bits left
}

The same shape appears in setForbidden and clearForbidden (broker/src/main/java/org/apache/rocketmq/broker/config/v1/RocksDBSubscriptionGroupManager.java:287-306; the updateForbidden variant is at :276-284).

On the next start the stored value is fed back into the loader, which expects a JSON object of topic → bits:

protected void decodeForbidden(byte[] key, byte[] body) {
    JSONObject jsonObject = JSON.parseObject(new String(body, RocksDBConfigManager.CHARSET));
    Set<Map.Entry<String, Object>> entries = jsonObject.entrySet();   // NPE for a "null" body
    ...
}

(:263-273.) JSON.parseObject("null") returns null, so the NullPointerException leaves loadForbidden through its catch and the method returns false (:101-109), loadSubscriptionGroupAndForbidden() returns false (:95-99), then RocksDBSubscriptionGroupManager.load() returns false (:81-83), BrokerController.initializeMetadata() returns false (BrokerController.java:863) and BrokerStartup answers that with System.exit(-3) (BrokerStartup.java:287-291) — the broker does not start until that key is repaired by hand.

The trigger needs nothing more than un-forbidding the last forbidden topic of a group; with a single forbidden topic that is the very first clear, so no multi-topic scenario is required. (The related cross-topic loss when a group has several forbidden topics is reported separately in #11093 — this report is about the value that gets persisted and what it breaks on the next load; the two fixes compose.)

Steps to Reproduce
  1. Start a broker with enableRocksDBStore=true and forbid a topic for a group, e.g. via UPDATE_AND_GET_GROUP_FORBIDDEN (AdminBrokerProcessor.updateAndGetGroupForbidden, :466-489) with readable=false for group=g, topic=t.
  2. Un-forbid the same topic (readable=true). The forbidden column family of group now holds the literal null.
  3. Restart the broker: the config load fails and the process exits (initialize() false → System.exit(-3)), with loadForbidden exception … java.lang.NullPointerException at decodeForbidden.

At the unit level, RocksDBSubscriptionGroupManagerTest already injects a mocked RocksDBConfigManager (no real RocksDB needed): forbidding then clearing one topic shows the "null" value being written today, and calling decodeForbidden(key, "null".getBytes()) throws.

What Did You Expect to See?

Clearing a group's forbidden state persists "no forbidden state": the key is removed (or at least stores a valid empty JSON object), and the loader tolerates an already written null body so that brokers which ran with the broken value can still start after upgrading.

What Did You See Instead?

A "null" value is written, and the next broker start aborts because the loader dereferences the parsed null; the failure mode is a broker that cannot start from its own persisted configuration.

Additional Context

Minimal fix in RocksDBSubscriptionGroupManager: route the three overrides through one helper that deletes the column-family key when the group has no forbidden bits left instead of writing JSON.toJSONString(null), and ignore an empty (null) body in decodeForbidden so existing stores recover. The sibling JSON mode persists the whole table, which is why it never hits this.

I will open a PR with those changes plus regression tests in RocksDBSubscriptionGroupManagerTest (red before: a "null" value is written / decodeForbidden throws; green after: the key is deleted and a null body is skipped).

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.