How to fix EXEC returns null - WATCH key modified, optimistic lock failed in Redis

What this error means

When Redis returns null from the EXEC command, it means at least one key you watched with WATCH was modified after the WATCH call but before EXEC attempted to execute the transaction. This is Redis's optimistic locking mechanism working as designed: WATCH monitors keys for changes, and if any modification occurs—whether from another client, expiration, eviction, or even your own commands outside the transaction—Redis aborts the entire MULTI/EXEC transaction to prevent working with stale data. The null return value is not an error but a signal that you need to retry the operation. Redis uses this check-and-set (CAS) behavior to guarantee that your transaction only executes if all watched keys remain unchanged, making it safe to perform read-modify-write operations in a multi-client environment without explicit locks.

Typical symptoms

• EXEC command returns null instead of an array of results, and no commands in the transaction are executed
• Application logs show repeated null responses from EXEC during high concurrency or when multiple clients modify the same keys
• Transaction retry logic triggers frequently, especially for hot keys that many clients access simultaneously
• Read-modify-write operations fail silently because the transaction aborted due to concurrent modifications
• Client libraries like node-redis, ioredis, or redis-py raise WatchError or similar exceptions when watched keys change

Common causes

1. Another client modified one or more watched keys between your WATCH and EXEC calls, causing the optimistic lock to fail
2. Your own code modified a watched key outside the MULTI/EXEC block after calling WATCH, which also triggers the abort condition
3. The watched key expired or was evicted by Redis's memory management policies (LRU/LFU) before EXEC ran, counting as a modification
4. High contention on hot keys means multiple clients are racing to update the same data, increasing the probability of conflicts
5. The retry logic is missing or incorrectly implemented, so the application doesn't attempt the transaction again after failure

How to fix "EXEC returns null - WATCH key modified, optimistic lock failed"

# In one Redis client, watch a key and start a transaction
redis-cli
WATCH mykey
GET mykey
MULTI
SET mykey "new-value"
# Don't run EXEC yet

# In a second Redis client, modify the watched key
redis-cli SET mykey "modified-by-client-2"

# Back in the first client, run EXEC
EXEC
# Returns: (nil) because mykey was modified

// Node.js with node-redis or ioredis
async function incrementCounter(client, key, maxRetries = 10) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      await client.watch(key);
      
      // Read current value
      const current = await client.get(key);
      const newValue = (parseInt(current || '0', 10) + 1).toString();
      
      // Execute transaction
      const multi = client.multi();
      multi.set(key, newValue);
      const results = await multi.exec();
      
      // Check for null (transaction aborted)
      if (results === null) {
        console.log(`Attempt ${attempt + 1} failed, retrying...`);
        continue;
      }
      
      // Success
      console.log(`Transaction succeeded on attempt ${attempt + 1}`);
      return newValue;
    } catch (err) {
      await client.unwatch();
      throw err;
    }
  }
  
  throw new Error(`Transaction failed after ${maxRetries} attempts`);
}

async function incrementWithBackoff(client, key, maxRetries = 10) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    await client.watch(key);
    
    const current = await client.get(key);
    const newValue = (parseInt(current || '0', 10) + 1).toString();
    
    const multi = client.multi();
    multi.set(key, newValue);
    const results = await multi.exec();
    
    if (results !== null) {
      return newValue;
    }
    
    // Exponential backoff: 2^attempt ms, max 100ms
    const delay = Math.min(Math.pow(2, attempt), 100);
    await new Promise(resolve => setTimeout(resolve, delay));
  }
  
  throw new Error('Max retries exceeded');
}

-- Increment counter atomically (increment.lua)
local current = redis.call('GET', KEYS[1]) or '0'
local newValue = tostring(tonumber(current) + 1)
redis.call('SET', KEYS[1], newValue)
return newValue

// Execute the Lua script
const result = await client.eval(
  fs.readFileSync('./increment.lua', 'utf8'),
  1,
  'mycounter'
);

// Shard counter across multiple keys
async function incrementShardedCounter(client, baseKey, numShards = 10) {
  const shard = Math.floor(Math.random() * numShards);
  const shardKey = `${baseKey}:shard:${shard}`;
  
  // Simple INCR, no WATCH needed for single key operations
  return await client.incr(shardKey);
}

// Read total count by summing all shards
async function getTotalCount(client, baseKey, numShards = 10) {
  const pipeline = client.pipeline();
  for (let i = 0; i < numShards; i++) {
    pipeline.get(`${baseKey}:shard:${i}`);
  }
  const results = await pipeline.exec();
  return results.reduce((sum, [err, val]) => sum + parseInt(val || '0', 10), 0);
}

Advanced notes

Frequently asked questions

What does "EXEC returns null - WATCH key modified, optimistic lock failed" mean?

When Redis returns null from the EXEC command, it means at least one key you watched with WATCH was modified after the WATCH call but before EXEC attempted to execute the transaction. This is Redis's optimistic locking mechanism working as designed: WATCH monitors keys for changes, and if any modification occurs—whether from another client, expiration, eviction, or even your own commands outside the transaction—Redis aborts the entire MULTI/EXEC transaction to prevent working with stale data. The null return value is not an error but a signal that you need to retry the operation.

How do I fix "EXEC returns null - WATCH key modified, optimistic lock failed"?

Redis returns null from EXEC when a watched key was modified between WATCH and EXEC, indicating the optimistic lock failed and the transaction was aborted. This is expected behavior for Redis optimistic locking, ensuring data consistency when multiple clients access the same keys. This guide explains why EXEC returns null, how to implement proper retry logic, and strategies to minimize transaction conflicts.

What causes "EXEC returns null - WATCH key modified, optimistic lock failed"?

Another client modified one or more watched keys between your WATCH and EXEC calls, causing the optimistic lock to fail Your own code modified a watched key outside the MULTI/EXEC block after calling WATCH, which also triggers the abort condition The watched key expired or was evicted by Redis's memory management policies (LRU/LFU) before EXEC ran, counting as a modification

Is the "EXEC returns null - WATCH key modified, optimistic lock failed" error serious?

It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Related errors

• ERR EXEC without MULTI

  How to fix "ERR EXEC without MULTI" in Redis

  HIGH

• ERR XREADGROUP requires GROUP option

  How to fix "ERR XREADGROUP requires GROUP option" in Redis

  MEDIUM

• EXECABORT Transaction discarded due to previous errors

  How to fix "EXECABORT Transaction discarded due to previous errors" in Redis

  MEDIUM

• ERR wrong number of arguments

  How to fix "ERR wrong number of arguments" in Redis

  MEDIUM

• WRONGPASS invalid username-password pair

  WRONGPASS invalid username-password pair in Redis

  HIGH

• LOADING Redis is loading the dataset in memory

  How to fix 'LOADING Redis is loading the dataset in memory' error

  MEDIUM

Official resources & further reading

• 📚Redis Official Documentation
• Redis docs - Transactions
• Redis docs - Transactions and optimistic locking
• DEV Community - Redis Transactions Made Easy
• Medium - Understanding Transactions in Redis
• node-redis issue #1349 - WATCH documentation