[Bug] BitsArray.toString renders an out-of-range padding bit for partial-byte arrays #11462

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

Windows 11; deterministic utility tests and the native Maven filter test suite. No broker or live message-loss reproduction is claimed.

RocketMQ version

develop, revision 5.5.1, commit 57c2dc0.

JDK Version

OpenJDK 1.8.0_302 (GraalVM CE 21.2.0), Maven 3.6.3.

Describe the Bug

When the most significant byte is only partially used, toString() starts at bitLength % Byte.SIZE rather than one less. It renders one extra padding bit, changes the output width and can expose a nonzero bit outside the logical array. Full-byte arrays take another branch and do not expose the problem.

Steps to Reproduce

BitsArray one = BitsArray.create(1);
one.setBit(0, true);
one.toString(); // "01\n", expected "1\n"

BitsArray seven = BitsArray.create(7);
seven.setByte(0, (byte) 0x80);
seven.toString(); // "10000000\n", expected "0000000\n"

BitsArray nine = BitsArray.create(9);
nine.setBit(8, true);
nine.setBit(0, true);
nine.toString(); // extra leading zero, 10 bit characters instead of 9

What Did You Expect to See?

Ignoring the existing newline grouping, exactly bitLength bit characters are rendered, from high logical bit to low logical bit. Padding outside that range is omitted. Whole-byte and zero-length output remain unchanged.

What Did You See Instead?

Every non-byte-aligned positive length renders one extra bit; for a nonzero padding bit the printed result includes data outside the logical array.

Additional Context

A one-line loop-bound correction and four regression methods are prepared. The baseline has 3 failing rendering tests out of 4; all four pass after the fix. An independent Java 8 native filter run executes all 7 filter test classes: 113 tests passed, 0 failures/errors/skips, with Checkstyle and SpotBugs passing.

This differs from #11458 (constructor/clone capacity) and #10506 (position bounds). The regular broker diagnostic caller normally supplies full bytes, so this report concerns the valid partial-byte utility contract rather than an asserted production message failure. Issue/PR and BitsArray discussion searches found no existing rendering fix.

AI assistance: OpenAI Codex was used for investigation, implementation and tests.