BatchOperate does not return KEY_NOT_FOUND for TTL-expired keys in mixed batch

[abhi022002]

We’re using the v8 Aerospike Go client and observed inconsistent behavior when using BatchOperate to delete TTL-expired keys.

Expected Behavior

If a key has expired due to TTL, we expect BatchOperate to DELETE return a KEY_NOT_FOUND_ERROR for that key, regardless of whether it is in a batch by itself or grouped with other valid keys.

Observed Behavior

• When a TTL-expired key is passed alone in BatchOperate as a BatchDelete, the response contains a KEY_NOT_FOUND_ERROR as expected.
• However, if the same expired key is included in a BatchOperate along with valid keys, the operation returns OK, and no error is returned for the expired key.

This is causing silent inconsistencies in our service logic, as we rely on per-key error codes for downstream handling.

Client Version:
github.com/aerospike/aerospike-client-go/v8 v8.1.0

Cluster Mode:
AP mode

Repro Steps:

• Insert a key with short TTL (e.g., 5s)
• Wait for it to expire
• Perform BatchOperate on BatchDelete:
• Case A: Only expired key → returns KEY_NOT_FOUND_ERROR ✅
• Case B: Expired key + valid keys → returns OK, no error for expired key ❌

[khaf]

Sorry this report flew under our radar. We will take care of it immediately.