packages/redis/src/memory-adapter.ts (5)

210-219: Use pipeline batching for addMessages.

The sequential await in the loop causes N round trips to Redis. Use a pipeline for better performance, consistent with other batch operations in this adapter.

♻️ Proposed batched implementation

   async addMessages(
     messages: UIMessage[],
     userId: string,
     conversationId: string,
-    context?: OperationContext,
+    _context?: OperationContext,
   ): Promise<void> {
-    for (const message of messages) {
-      await this.addMessage(message, userId, conversationId, context);
+    if (messages.length === 0) return;
+
+    const pipeline = this.client.pipeline();
+    for (const message of messages) {
+      const createdAt = (message as UIMessage & { createdAt?: Date }).createdAt ?? new Date();
+      const entry = safeStringify({
+        ...message,
+        userId,
+        conversationId,
+        createdAt: createdAt.toISOString(),
+      });
+      pipeline.zadd(this.key("msgs", conversationId), createdAt.getTime(), entry);
     }
+    await pipeline.exec();
+
+    this.log("addMessages", { count: messages.length, conversationId });
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/src/memory-adapter.ts` around lines 210 - 219, The current
addMessages method awaits addMessage in a loop causing N Redis round-trips;
change it to build and execute a single Redis pipeline: create a pipeline from
the Redis client, for each UIMessage enqueue the same Redis commands that
addMessage performs (or factor out the low-level Redis command sequence into a
helper and call it to populate the pipeline) including any score/member ZADD,
HSET or EXPIRE operations and any conversation/message index updates, preserving
the userId, conversationId and context behavior; then execute pipeline.exec()
and handle/report errors similarly to addMessage so the batch is applied in one
round trip.

---

53-67: Consider handling Redis connection events.

The adapter doesn't handle Redis connection lifecycle events (error, reconnect, close). For production use, consider exposing error events or adding connection status tracking.

Would you like me to suggest an implementation with connection event handling?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/src/memory-adapter.ts` around lines 53 - 67, Add Redis
connection event handling to RedisMemoryAdapter: in the constructor after
initializing this.client, attach listeners for 'error',
'reconnecting'/'connect'/'ready' and 'close' to update an internal connection
status field (e.g., this.connected or this.connectionState) and to re-emit or
surface errors via an EventEmitter stored on the adapter (e.g., this.events) so
callers can subscribe; update the class signature to include the connection
state field and an EventEmitter and ensure listeners use unique handler
functions so they can be removed in a future close() or dispose() method on
RedisMemoryAdapter (reference RedisMemoryAdapter, constructor, this.client, and
add new this.events/this.connectionState and a close()/dispose() method).

---

375-398: N+1 query pattern in queryWorkflowRuns.

The loop fetches each workflow state individually (line 386), causing N Redis round trips after fetching the ID list. Consider batching the GET operations using a pipeline, similar to getConversationsByIds.

♻️ Proposed batched implementation

   async queryWorkflowRuns(query: WorkflowRunQuery): Promise<WorkflowStateEntry[]> {
     let ids: string[];
     if (query.workflowId) {
       ids = await this.client.zrevrange(this.key("wf:idx", query.workflowId), 0, -1);
     } else {
       ids = await this.client.zrevrange(this.key("wf:all"), 0, -1);
     }
 
+    if (ids.length === 0) return [];
+
+    // Batch fetch all workflow states
+    const pipeline = this.client.pipeline();
+    for (const id of ids) {
+      pipeline.get(this.key("wf", id));
+    }
+    const pipelineResults = await pipeline.exec();
+
     const results: WorkflowStateEntry[] = [];
-    for (const id of ids) {
-      const state = await this.getWorkflowState(id);
+    for (const [err, data] of pipelineResults ?? []) {
+      if (err || !data) continue;
+      const state = this.deserializeWorkflowState(JSON.parse(data as string));
       if (!state) continue;
       if (query.status && state.status !== query.status) continue;
       if (query.userId && state.userId !== query.userId) continue;
       if (query.from && state.createdAt < query.from) continue;
       if (query.to && state.createdAt > query.to) continue;
       results.push(state);
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/src/memory-adapter.ts` around lines 375 - 398,
queryWorkflowRuns does N+1 by calling getWorkflowState(id) inside the loop;
replace the per-id round trips with a batched Redis pipeline/mget to fetch all
workflow state entries in one call (similar to getConversationsByIds). Build a
pipeline for each id using the same Redis key used by getWorkflowState (e.g.
this.key("wf", id) or the underlying storage command used by getWorkflowState),
execute the pipeline, parse/deserialise results into WorkflowStateEntry, then
apply the existing status/userId/from/to filters and offset/limit slicing; keep
getWorkflowState for single reads but implement the bulk fetch inside
queryWorkflowRuns to avoid the N Redis round trips.

---

62-66: Simplify redundant connection handling.

Both branches create a Redis instance identically. The Redis constructor from ioredis accepts either a string URL or an options object, so the conditional is unnecessary.

♻️ Proposed simplification

-    if (typeof options.connection === "string") {
-      this.client = new Redis(options.connection);
-    } else {
-      this.client = new Redis(options.connection);
-    }
+    this.client = new Redis(options.connection);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/src/memory-adapter.ts` around lines 62 - 66, The conditional
creating the Redis client is redundant: both branches call new
Redis(options.connection). Replace the if/else with a single instantiation
(assign this.client = new Redis(options.connection)); ensure the constructor or
surrounding code accepts options.connection as either string or config object
and remove the unused conditional branch (symbols: options.connection,
this.client, Redis).

---

237-243: Consider defensive JSON parsing.

Multiple JSON.parse calls (lines 114, 238, 290, 321, 372, 469) lack try-catch. While data is written via safeStringify, corrupted or manually modified Redis data could cause unhandled exceptions. Consider wrapping in try-catch or using a safe parse utility for resilience.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/src/memory-adapter.ts` around lines 237 - 243, Wrap the
JSON.parse call inside the entries.map in a defensive try-catch (or replace with
a safeParse utility) so corrupted/manually modified Redis payloads don't throw;
on parse failure for an entry, skip that entry (or return null) and filter out
nulls afterward, and emit a warning via the module's logger (or console)
including the raw entry to aid debugging; apply the same pattern to other parse
sites (the other JSON.parse calls mentioned) so functions like the entries.map
that builds messages and the UIMessage<{ createdAt: Date }> construction are
resilient to bad data.

packages/redis/tsconfig.json (1)

4-4: Consider removing dom from lib for a server-side package.

The dom and dom.iterable libraries are typically unnecessary for a Redis adapter that runs exclusively in Node.js environments. Consider simplifying to just ["esnext"].

♻️ Suggested simplification

-    "lib": ["dom", "dom.iterable", "esnext"],
+    "lib": ["esnext"],

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/tsconfig.json` at line 4, Remove browser-specific libs from
the TypeScript config: update the "lib" array in tsconfig.json (the "lib"
property currently containing "dom" and "dom.iterable") to only include
server-appropriate libs such as "esnext" (or "es2020"/similar) so the Redis
adapter doesn't pull in DOM typings; edit the "lib" entry accordingly in the
tsconfig.json file where "lib": ["dom","dom.iterable","esnext"] is defined.

packages/redis/package.json (1)

9-13: Consider adding vitest as an explicit devDependency.

The vitest.config.mts uses Vitest APIs, but vitest itself is not listed as a devDependency—only @vitest/coverage-v8 is included. If the workspace provides Vitest at the root, this works, but adding it explicitly improves package portability and makes dependencies clearer.

♻️ Suggested addition

   "devDependencies": {
     "@vitest/coverage-v8": "^3.2.4",
     "@voltagent/core": "^2.4.4",
-    "ai": "^6.0.0"
+    "ai": "^6.0.0",
+    "vitest": "^3.2.4"
   },

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/redis/package.json` around lines 9 - 13, Add "vitest" as an explicit
devDependency in the package.json devDependencies block (alongside
"@vitest/coverage-v8"), so the package doesn't rely solely on a workspace root
for Vitest; pick a compatible version (e.g. "^1" or match the workspace root)
and update the "devDependencies" object to include "vitest": "<version>" to
ensure vitest.config.mts and any Vitest APIs resolve locally for this package.