Documentation for agents: an index at /llms.txt, every docs page in one file at /llms-full.txt, and Markdown for any docs page by adding .md to its URL.

Effect KitRedis

Pipelines

Send several commands in one round trip and get one result per command.

A pipeline writes several commands before it waits for any reply, then returns one Result per command in the same order. Each command keeps its own success type, and one failure does not hide the others.

Example (Pipelining a Write and a Counter)

import { ,  } from "effect";

import { Commands,  } from "@effect-kit/redis";

const  = .(function* () {
  const  = yield* ;

  const  = yield* .([
    Commands.("{account:42}:name", "Ada"),
    Commands.("{account:42}:visits"),
  ]);

  const [saved, ] = ;
         
const saved: Result<void, ReplyError | ServerError>

  if (.()) return yield* .;

  return .;
});

redis.pipeline takes Commands.* values. The result is a tuple, so saved is typed for set and visits for incr. The Effect fails only when the batch as a whole fails. A command the server rejects comes back as a Failure inside the tuple.

Pipelines are not atomic

A pipeline is not a transaction. Other clients can run commands between yours, and commands that succeed stay applied when a later one fails. Use a transaction when the commands must run together.

Checking each result

A failing command does not fail the pipeline, so the Effect succeeds even when a result is a Failure. Ignoring the results hides the error.

Example (Reading a Failure From a Pipeline)

import { ,  } from "effect";

import { Commands,  } from "@effect-kit/redis";

const  = .(function* () {
  const  = yield* ;

  const [, ] = yield* .([
    Commands.("profile:name", "Ada"),
    Commands.("profile:name"),
  ]);

  // Wrong: the pipeline succeeded, but INCR failed on a text value.
  // return "ok";

  // Right: look at each result. SET is still applied.
  if (.()) {
    return `set ok: ${.()}, incr failed: ${..}`;
  }

  return "both ran";
});
// Output: set ok: true, incr failed: ServerError

Each failure is a ServerError or a ReplyError, or an error from a custom decoder.

When the whole batch fails

If the connection fails or the fiber is interrupted partway through, the pipeline fails with a BatchError. Its outcomes field is Redacted because replies can hold your data. It records what happened to each command by index: Completed, Replied, Unsent or Unknown.

Example (Inspecting Per-Command Outcomes)

import { ,  } from "effect";

import { Commands,  } from "@effect-kit/redis";

const  = .(function* () {
  const  = yield* ;

  return yield* 
    .([Commands.("jobs:done"), Commands.("jobs:total")])
    .(
      .("BatchError", () =>
        .(.(.).(() => .)),
      ),
    );
});

A slot marked Unsent never reached the server. A slot marked Unknown may have run. execution on the error summarizes the batch: partial-or-unknown, not-executed, unknown or replied.

Batch limits

A pipeline holds at most maxBatchCommands commands, which defaults to 256. A longer one fails before anything is written, with a SessionError whose reason is "batch-limit". An empty pipeline returns [].

Set the limit in the layer's sessions options.

Example (Raising the Batch Limit)

import {  } from "@effect-kit/redis/node";

export const  = .({
  : "redis://localhost:6379",
  : { : 1000 },
});

On a cluster, give the keys in one pipeline the same hash tag, as the {account:42} keys above do. See multi-key commands.

On this page

Checking each resultWhen the whole batch failsBatch limits