# Redis 8.8 adds arrays and explicit Streams message rejection > Redis 8.8 introduces arrays, window counters and XNACK; consumer reclaim settings remain essential to making rejected messages available again. Canonical URL: https://www.devobs.io/news/news-redis-88-arrays-stream-nack/ By: Claire Dubois Published: 2026-09-06T11:58:54.645Z Updated: 2026-09-06T11:58:54.645Z Event date: 2026-06-02 Section: Data Redis announced version 8.8 on June 2, adding a numeric-indexed array data structure, a window-counter primitive and explicit rejection of pending Streams messages. The [release post](https://redis.io/blog/announcing-redis-8-8/) says the features are generally available in Redis Open Source. ## New structures change application choices Arrays support indexed string values, sparse positions and bounded rolling-buffer use. The `INCREX` counter operation adds bounds and expiration controls useful for window-based rate limiting. Our analysis is that these are opportunities to simplify specific application operations, not a reason to replace every existing list or hash. Compare the access pattern first: numeric-position lookup, named-field lookup and queue-like operations have different requirements. For a counter migration, preserve the intended window and rejection semantics. Test requests at the boundary, concurrent increments and expiration rather than checking only that the counter increases. ## Rejection needs a matching consumption policy The new `XNACK` command releases pending messages for redelivery. Its modes distinguish transient failures, work that may succeed elsewhere and fatal messages through delivery-counter handling. The announcement's consumption rule is important: `XREADGROUP` with `CLAIM` prioritizes rejected messages; without `CLAIM`, it continues returning only never-delivered messages. Fatal marking also does not itself implement an application's dead-letter destination. Before adopting the command, rehearse a worker shutdown, an unavailable dependency and a poison record. Confirm who receives each message next and when the application stops retrying it. Keep idempotent handling for external effects, since faster redelivery does not establish that earlier work never completed. Start with one consumer group and verify the entire reject, reclaim and quarantine path, including its actual client options. ## Source references -