Valkey 9.2's INCREX closes the crash gap that strands INCR/EXPIRE counters without a TTL

The pattern INCREX replaces is three lines of application code, as the post's author writes them ^[9]:

```python val = r.incr(key) if val == 1: r.expire(key, 60) ```

Here is what happens when the process dies between the second and third lines. The increment has landed and the key holds 1. The next request gets 2, fails the check and skips EXPIRE. So does every request after it ^[20]. The author wrote that each such crash leaves "exactly one permanently orphaned key, because the increment already landed and nothing will ever set its expiry" ^[13].

INCREX ^[5] has no in-between state for a crash to land in. Either the process dies before the single command is sent and nothing happened, or it dies after the command completed and the key already holds its new value and its TTL ^[14].

The crash test gave each request a 2% chance of failing after the first command, and the observed rate came out at 2.2% ^[12][19]. That rate does not carry straight into production. Only the request whose INCR returns 1 runs EXPIRE, so only a crash on that request strands a key ^[20]. A counter that takes many increments per window creates its key once. The production orphan rate is therefore the crash rate on first increments, and each orphan persists ^[13].

The speed numbers came from Docker containers on one host, driven by redis-py 8.1.0 over localhost TCP ^[10]. The pipelined control run is the best thing in the post. It removes the second network wait, and what is left is the server-side difference ^[2]. That pipeline also drops the conditional and queues INCR and EXPIRE on every call, with transaction=False ^[11]. That is fine for a benchmark. In a limiter, an EXPIRE on every request sets the 60-second deadline again each time, so the window no longer starts at the first increment ^[21]. The post's own code makes the author's point that pipelining a conditional increment "is awkward enough that people skip it" ^[3].

I'd expect the blocking pattern's penalty to grow on a real network. It waits on the network twice per request, and a localhost round trip is about as short as round trips get ^[9][10].

Fixed-window quotas depend on later increments leaving the first TTL alone, which is the behaviour the 20-thread run showed ^[15]. The post does not show which flags those threads passed. The plain EX form's behaviour on an existing key needs its own check before a quota counter depends on it.

The build tested is a release candidate, the newest valkey/valkey tag on Docker Hub when the post was written ^[17]. The author wrote, "The round trip is not the part of this that matters." ^[18]