test(redis): wait for follower apply catch-up in MultiExec list tests

TestRedis_MultiExec_DelThenRPushRecreatesList was intermittently failing
under -race on CI (PR #577): after MULTI / DEL list / RPUSH list new1
new2 / EXEC, the final direct store.ScanAt(..., readTS) on nodes[1]
returned the pre-EXEC ["old1","old2"] even though the immediately
preceding LRANGE via the redis client correctly returned
["new1","new2"].

Why the race exists:
- The go-redis client connects to nodes[1], which is not necessarily the
  raft leader.
- LRANGE goes through the adapter's LeaseRead / LinearizableRead path,
  which blocks until the local apply watermark reaches a safe point, so
  it observes the EXEC commit even on a slightly-lagging follower.
- readTS() (adapter/ts.go:snapshotTS) returns the local store's
  LastCommitTS() directly, with no wait-apply. On a follower (or a
  leader that has just responded to the client), LastCommitTS can
  momentarily trail the raft-committed EXEC because the test reads it
  on a different code path than the one that drove the client-visible
  wait.
- The direct ScanAt(readTS) therefore sees the stale, pre-EXEC state.

Fix: introduce waitForListState(t, node, key, expectedLen,
expectedValues) that polls resolveListMeta AND the raw item scan at the
node-local readTS via require.Eventually (250ms interval, 5s timeout)
until both reflect the expected post-EXEC state. This is a real
synchronization on the raft apply progress of the target node, not a
timing hack: it succeeds on the first iteration when the node is
already caught up and only retries while the apply is genuinely behind.

Use it in place of the ad-hoc readTS/resolveListMeta/ScanAt block in
TestRedis_MultiExec_DelThenRPushRecreatesList.

Author: bootjp

adapter/redis_multi_test.go

@@ -5,13 +5,63 @@ import (
 	"math"
 	"strconv"
 	"testing"
+	"time"
 
 	"github.com/bootjp/elastickv/store"
 	"github.com/redis/go-redis/v9"
 	"github.com/stretchr/testify/assert"
 	"github.com/stretchr/testify/require"
 )
 
+// waitForListState polls until this node has applied raft commits such that
+// the list stored under key resolves to expectedLen items whose values match
+// expectedValues (when non-nil) via both resolveListMeta and a direct scan at
+// the node-local readTS.
+//
+// Why this is necessary: the go-redis client may be connected to a follower
+// (or a leader that momentarily lags in applying its own commit). The adapter's
+// client-facing read path (LRANGE) uses LeaseRead/LinearizableRead so it
+// blocks until the local apply catches up, which is why LRANGE observes the
+// new state. However readTS() returns store.LastCommitTS() directly, and a
+// direct ScanAt(readTS) bypasses that wait. When the client and the direct
+// scan target the same node, there is still a window between the client
+// receiving the EXEC reply (driven by the wait-apply inside read handlers) and
+// the raft-applied commit updating LastCommitTS on this node's store — in
+// particular when this node was not the proposer and applies strictly after
+// the response was delivered via a different code path. Polling resolves the
+// gap deterministically without a timing-based sleep.
+func waitForListState(t *testing.T, n Node, key []byte, expectedLen int, expectedValues []string) {
+	t.Helper()
+	ctx := context.Background()
+	require.Eventually(t, func() bool {
+		readTS := n.redisServer.readTS()
+		meta, exists, err := n.redisServer.resolveListMeta(ctx, key, readTS)
+		if err != nil || !exists || meta.Len != int64(expectedLen) {
+			return false
+		}
+		kvs, err := n.redisServer.store.ScanAt(
+			ctx,
+			store.ListItemKey(key, math.MinInt64),
+			store.ListItemKey(key, math.MaxInt64),
+			expectedLen+1,
+			readTS,
+		)
+		if err != nil || len(kvs) != expectedLen {
+			return false
+		}
+		if expectedValues == nil {
+			return true
+		}
+		for i, kvp := range kvs {
+			if string(kvp.Value) != expectedValues[i] {
+				return false
+			}
+		}
+		return true
+	}, 5*time.Second, 250*time.Millisecond,
+		"node did not catch up to expected list state for key %q (len=%d)", string(key), expectedLen)
+}
+
 func TestRedis_MultiExecAtomic(t *testing.T) {
 	t.Parallel()
 	nodes, _, _ := createNode(t, 3)
@@ -194,31 +244,12 @@ func TestRedis_MultiExec_DelThenRPushRecreatesList(t *testing.T) {
 	require.NoError(t, err)
 	require.Equal(t, []any{"new1", "new2"}, rangeRes)
 
-	readTS := nodes[1].redisServer.readTS()
-
 	// With the Delta pattern, RPUSH inside a MULTI/EXEC emits a delta key
-	// rather than updating the base metadata key directly.  Verify the
-	// effective metadata via resolveListMeta which aggregates deltas.
-	resolvedMeta, resolvedExists, err := nodes[1].redisServer.resolveListMeta(ctx, []byte("list-del-rpush"), readTS)
-	require.NoError(t, err)
-	require.True(t, resolvedExists)
-	require.Equal(t, int64(2), resolvedMeta.Len)
-
-	kvs, err := nodes[1].redisServer.store.ScanAt(
-		ctx,
-		store.ListItemKey([]byte("list-del-rpush"), math.MinInt64),
-		store.ListItemKey([]byte("list-del-rpush"), math.MaxInt64),
-		10,
-		readTS,
-	)
-	require.NoError(t, err)
-	require.Len(t, kvs, 2)
-
-	got := make([]string, 0, len(kvs))
-	for _, kvp := range kvs {
-		got = append(got, string(kvp.Value))
-	}
-	require.Equal(t, []string{"new1", "new2"}, got)
+	// rather than updating the base metadata key directly. Additionally, the
+	// node the client is connected to may apply the EXEC commit slightly
+	// after the client receives its response, so poll until this node's
+	// store has caught up before asserting on the raw scan.
+	waitForListState(t, nodes[1], []byte("list-del-rpush"), 2, []string{"new1", "new2"})
 }
 
 func TestRedis_MultiExec_SetGetAfterDeleteReturnsNilOldValue(t *testing.T) {