General status update, second-half 2026

[mgravell]

Partly a general update, partly a response to some recent questions

Firstly: highlights - what have I/we been up to recently?

1. major overhaul of the IO core, with v3 - this is split into 4 pieces:

• the "internal" read loop: delivered in v3
• the "public" read loop: the first wave of this is being added in add ReadOnlyMemory<RedisKeyOrValue> and Lease<byte> for Lua and Execute #3201, opening the way for highly efficient external modules / add-ins / etc
• the "internal" write loop: upcoming v3.x - this moves the write overhead directly to the caller, hugely improving throughput and removing a complex timing problem re leased args
• the "public" write loop: upcoming v3.y - same thing, but for external callers

2. major client feature releases

• geo-redundant-failover ("active:active") - delivered in v3.1
• smart-client-handoffs ("hitless") - imminent

3. ongoing performance, stability, and feature / API bits - literally too many to cite individually! releases
4. keeping on top of the issue tracker - at the time of writing, the most recent open user issue is from May, with a couple newer by myself as placeholders; slowly whittling away at the older things too, but fundamentally: not stagnating

So: all going well, IMO - huge active work - I think we're in a very healthy place.

---

To address some questions / criticisms:

1. blocking operations: WAIT, BRPOP, etc - yes, there is a frustrating fundamental mismatch between the competing needs here - directly blocking operations are incompatible with multiplexing. You might, then, reasonable ask "then why are you using a multiplexer?" - great and valid question! With a simple answer: scalability. This isn't a limitation of the library; it is a huge feature - in fact, multiple other libraries are actively trying to move towards multiplexing, because at scale: every other approach does not work. In theory, we could try to add a secondary pool for blocking operations, but that is adding massive complexity and retains the scaling problem. What I would much rather do is continue trying to convince server to properly support async blocking completions. I will raise this again, as it is the only solution that correctly and efficiently addresses the actual problem.
2. cancellation tokens: great news for you, this is actually fully working and implemented in the internal PoC of the 3.x write loop changes, as cited above; this is expected to land in the above work
3. connection pooling: see point 1 above; the multiplexer side-steps this
4. missing modules for things like FT.SEARCH, as provided by NRedisSearch; since I literally maintain NRedisSearch, this is more a matter of location rather than anything being "missing"; I'm not sure we gain much by relocating them, since they are readily available. A valid and reasonable observation might be "but that has more overhead" - which is where the public write loop and public read loop (see top list) come in!