removeObjects() stops after a batch with an error, so later batches are never deleted

[allanrogerr]

removeObjects() sends the requested objects to the server in batches of 1000. When a batch returns any error other than NoSuchVersion, the iterator sets completed = error != null (MinioAsyncClient.java line 1120 on master), so it stops after reporting that batch's errors and never sends the remaining batches. The caller sees only the failing batch's errors, and nothing indicates that the later objects were not deleted.

Steps to reproduce

1. Create a bucket with object lock enabled, and put 1500 objects (obj-0000 to obj-1499).
2. Enable legal hold on obj-0010.
3. Call removeObjects() with all 1500 object names and version IDs, and iterate every result.
4. List the object versions left in the bucket.

Actual result

One error is reported (obj-0010, InvalidRequest), and 501 object versions remain: obj-0010 plus all 500 objects in the second batch.

Expected result

One error is reported, and only obj-0010 remains.

Details

• I ran this against AIStor RELEASE.2026-08-07T18-34-35Z with the SDK built from Fix bugs found during code audit across api, adminapi, functional, examples #1711 at 0b581976, where removeObjects() is identical to master.
• With the completed = error != null; line removed, the same run reports the same error and leaves 1 object version.
• Do not set completed if NoSuchVersion in removeObjects #1710 changed this line from completed = true, so a batch whose only errors are NoSuchVersion no longer ends the iteration; any other error still does.
• CodeRabbit (review) and a reviewer (review) raised this on Fix bugs found during code audit across api, adminapi, functional, examples #1711, where it was deferred to a separate issue.

[balamurugana]

@allanrogerr This is design choice i.e. As it is removal/unrecoverable, stop immediately on first error than removing for all batches. Could you share why do we need this behavior?