Report per-record errors in batch_operate instead of aborting the batch

[zuchmanski]

Problem

Client#batch_operate (with BatchWrite / BatchUDF / BatchDelete / BatchRead records) raised Aerospike::Exceptions::Aerospike and abandoned the entire batch as soon as one record came back with a non-OK result code (e.g. RECORD_TOO_BIG, PARAMETER_ERROR, BIN_TYPE_ERROR).

As a result:

1. A single bad record failed every other record in the batch — successful writes were lost / unreadable.
2. The caller couldn't do partial-failure handling: the exception carried no per-record context and BatchRecord#result_code was never populated for the failing (or any subsequent) record.

Per-record failures should be reported on each BatchRecord#result_code, leaving successful records applied/returned and the call succeeding — the point of a batch, and how the Java/C/Go clients behave (respond_all_keys).

Root cause

MultiCommand#parse_group raised on any per-record code that wasn't OK / KEY_NOT_FOUND_ERROR / FILTERED_OUT, before parse_row recorded the code. BatchOperateCommand#parse_row already stores the per-record code, but never ran on the failing record because parse_group raised first; the exception then propagated out via threads.each(&:join) in execute_batch_operate_commands.

Fix

• Extract the raise decision from MultiCommand#parse_group into an overridable handle_result_code(result_code). Base behavior is unchanged (raises on unexpected codes).
• Override handle_result_code as a no-op in BatchOperateCommand, so non-OK codes fall through to parse_row and are captured on each BatchRecord#result_code. The call returns normally and the caller inspects status per record.

Scan/query (StreamCommand, which has its own parse_group) and legacy batch_get (BatchIndexCommand) keep the existing raising behavior.

Testing

Added a spec that mixes a healthy BatchWrite with one that deterministically fails (Operation.add on a pre-existing string bin → BIN_TYPE_ERROR), asserting the call doesn't raise, the good record is OK with its record set, the bad record carries BIN_TYPE_ERROR, and the good write is durably readable.

Verified against a live Aerospike 7.1 server:

• New test fails without the fix (raises out of batch_operate) and passes with it.
• batch_operate_spec.rb + batch_spec.rb: 33 examples, 0 failures (legacy batch_get raising path intact).

🤖 Generated with Claude Code