@oneunit/redis 0.0.0-stage → 1.0.0

package/examples/_setup.js

@@ -0,0 +1,143 @@
+/**
+ * Shared setup for the examples in this directory.
+ *
+ * Every example needs the same three things: a Redis URL, a decision about
+ * whether to log connection events, and a clean shutdown. Keeping that here
+ * means each example file can be about its actual subject.
+ *
+ * These are run straight from a checkout (`npm run example:<name>`), so they
+ * import the package by name rather than by relative path. Node resolves that
+ * through the package's own `exports` map, which means the examples exercise
+ * the same entry points a consumer gets.
+ */
+
+import { silentLogger } from "@oneunit/redis";
+
+export const REDIS_URL = process.env.REDIS_URL ?? "redis://localhost:6379";
+
+/**
+ * Connection-event logging is noisy in a demo, so `REDIS_SILENT=true` turns it
+ * off. Passing `undefined` instead lets `createClient` skip the log calls while
+ * still registering the ioredis `error` listener, which is what keeps a
+ * transient outage from becoming an unhandled exception.
+ */
+export const exampleLogger =
+  process.env.REDIS_SILENT === "true" ? silentLogger : undefined;
+
+/** Resolve after `ms`, used to space out publishes and let I/O settle. */
+export function sleep(ms) {
+  return new Promise((resolve) => setTimeout(resolve, ms));
+}
+
+/**
+ * Resolve to `"timeout"` if `promise` has not settled within `ms`.
+ *
+ * Worth having in every example. ioredis queues commands while reconnecting and
+ * BullMQ waits on its own readiness, so against an unreachable server calls like
+ * `subscribe()` or `worker.waitUntilReady()` never settle at all. Without a
+ * bound the script hangs until someone kills it, which looks identical to a
+ * Redis that is merely slow.
+ *
+ * The timer is always cleared. A pending timeout keeps the event loop alive,
+ * so a losing race would silently add its full duration to the script's
+ * runtime.
+ */
+export async function within(promise, ms = 5000) {
+  let timer;
+  try {
+    return await Promise.race([
+      promise,
+      new Promise((resolve) => {
+        timer = setTimeout(() => resolve("timeout"), ms);
+      }),
+    ]);
+  } finally {
+    clearTimeout(timer);
+  }
+}
+
+/**
+ * True if `promise` settles successfully within `ms`, false on timeout or
+ * rejection.
+ *
+ * BullMQ readiness needs both guards. It rejects outright against a dead server
+ * ("Connection is closed") rather than hanging, so a timeout race alone is not
+ * enough. Letting that rejection escape would abort the example before it could
+ * shut down, and BullMQ's reconnect loops would then keep the process alive
+ * with nothing left to stop them.
+ */
+export async function isReady(promise, label, ms = 5000) {
+  try {
+    if ((await within(promise, ms)) === "timeout") {
+      console.log(`  ${label} not ready within ${ms}ms.`);
+      return false;
+    }
+  } catch (error) {
+    console.log(`  ${label} unavailable: ${error.message}`);
+    return false;
+  }
+  return true;
+}
+
+/**
+ * Resources registered here, closed in reverse order when the example finishes.
+ *
+ * Every example creates its own clients, and ioredis keeps a socket open for
+ * each one. If `main()` returns early or throws partway through, whoever was
+ * going to call `shutdown` never gets to run, so the open socket keeps the event
+ * loop alive and the script hangs until it is killed from outside. That turns a
+ * clear stack trace or a tidy "Redis is not reachable" message into a timeout.
+ *
+ * Cleanup always runs, not only on failure. Every registered close is a no-op
+ * once the resource is already gone, so running them unconditionally covers the
+ * early-return paths without asking each example to repeat its own teardown.
+ */
+const cleanups = [];
+
+/** Register `close` to run when the example ends. Later registrations close first. */
+export function onFailure(close) {
+  cleanups.push(close);
+}
+
+/**
+ * Close everything registered so far, in reverse order.
+ *
+ * Draining the list matters for more than tidiness. `shutdown` waits out a 5s
+ * QUIT deadline against an unreachable server, so a resource closed here and
+ * then closed again by `run` would cost that deadline twice. Once released, it
+ * is out of the list and cannot be closed again.
+ *
+ * Call this when the example shuts down by hand, so its own "disconnected
+ * cleanly" message is only printed after the connection is really gone.
+ */
+export async function release() {
+  const pending = cleanups.splice(0).reverse();
+
+  for (const close of pending) {
+    try {
+      await close();
+    } catch {
+      // A cleanup that throws must not hide the original failure.
+    }
+  }
+}
+
+/**
+ * Run an example's main function and make a failure visible in the exit code.
+ *
+ * `catch(console.error)` alone leaves the process exiting 0, so a broken example
+ * looks like a passing one in any script that checks `$?`.
+ */
+export async function run(name, main) {
+  try {
+    await main();
+  } catch (error) {
+    console.error(
+      `\n${name} failed:`,
+      error instanceof Error ? error.message : error,
+    );
+    process.exitCode = 1;
+  } finally {
+    await release();
+  }
+}

package/examples/cache.js

@@ -0,0 +1,111 @@
+/**
+ * Read-through cache: Redis in front of a slow "database".
+ *
+ *   npm run example:cache
+ *
+ * Environment:
+ *   REDIS_URL    connection URL (default redis://localhost:6379)
+ *   REDIS_SILENT set to "true" to suppress connection-event logging
+ *
+ * The point of the pattern is that the cache key, the TTL, and the
+ * serialisation all live in one place, so callers only ever see a plain object.
+ * The two failure modes worth knowing about are both shown below: a TTL that is
+ * too long serves stale data, and no TTL at all grows Redis without limit.
+ */
+
+import { createClient, health, shutdown } from "@oneunit/redis";
+import { REDIS_URL, exampleLogger, onFailure, release, run } from "./_setup.js";
+
+const CACHE_TTL_SECONDS = 60;
+const KEY_PREFIX = "example:cache:";
+
+await run("cache", async () => {
+  const client = createClient({ url: REDIS_URL }, exampleLogger);
+  onFailure(() => shutdown(client, exampleLogger));
+
+  const healthResult = await health(client);
+  if (healthResult.status === "down") {
+    // Always shut down, including on this early exit: ioredis retries in the
+    // background, so a client left open keeps the event loop alive and the
+    // script never exits.
+    console.log("Redis is not reachable, stopping here.");
+    console.log("Health:", healthResult);
+    await release();
+    return;
+  }
+
+  async function fetchUserFromDatabase(userId) {
+    // Stands in for a real query. The delay is what makes the cache worth
+    // having and makes the timing difference visible below.
+    await new Promise((resolve) => setTimeout(resolve, 50));
+    return {
+      id: userId,
+      name: `User ${userId}`,
+      email: `user${userId}@example.com`,
+    };
+  }
+
+  async function getUser(userId) {
+    const key = `${KEY_PREFIX}user:${userId}`;
+
+    const cached = await client.get(key);
+    if (cached !== null) {
+      console.log(`  HIT  ${key}`);
+      return JSON.parse(cached);
+    }
+
+    console.log(`  MISS ${key}`);
+    const user = await fetchUserFromDatabase(userId);
+
+    // SETEX writes the value and its TTL in one round trip, so the key can
+    // never end up stored without an expiry if the process dies midway.
+    await client.setex(key, CACHE_TTL_SECONDS, JSON.stringify(user));
+
+    return user;
+  }
+
+  console.log("First request:");
+  const started = Date.now();
+  const first = await getUser(123);
+  console.log("  ->", first, `(${Date.now() - started}ms, hit the database)`);
+
+  console.log("\nSecond request:");
+  const cachedStart = Date.now();
+  const second = await getUser(123);
+  console.log(
+    "  ->",
+    second,
+    `(${Date.now() - cachedStart}ms, served from Redis)`,
+  );
+
+  const ttl = await client.ttl(`${KEY_PREFIX}user:123`);
+  console.log(`\nCached entry expires in ${ttl}s.`);
+
+  // A negative TTL means the key has no expiry set, which is the bug to avoid
+  // in production: it survives deploys and restarts indefinitely.
+  if (ttl === -1) {
+    console.log("  WARNING: key has no TTL; it will never expire on its own.");
+  }
+
+  // Cache invalidation: delete the key so the next read repopulates it.
+  await client.del(`${KEY_PREFIX}user:123`);
+  console.log("\nInvalidated the entry.");
+
+  // SCAN rather than KEYS. KEYS blocks the server for the length of the scan,
+  // which on a large keyspace is a production outage.
+  const cursor = "0";
+  const [next, keys] = await client.scan(
+    cursor,
+    "MATCH",
+    `${KEY_PREFIX}*`,
+    "COUNT",
+    100,
+  );
+  console.log(
+    `SCAN from ${cursor} returned cursor ${next} and ${keys.length} matching keys.`,
+  );
+
+  await client.del(`${KEY_PREFIX}user:123`);
+  await release();
+  console.log("\nDisconnected cleanly.");
+});

package/examples/pipeline.js

@@ -0,0 +1,161 @@
+/**
+ * Batching many commands into one round trip with `runPipeline`.
+ *
+ *   npm run example:pipeline
+ *
+ * Environment:
+ *   REDIS_URL    connection URL (default redis://localhost:6379)
+ *   REDIS_SILENT set to "true" to suppress connection-event logging
+ *
+ * The point of the pattern is that N commands cost one network round trip
+ * instead of N. That only pays off for a batch you already have in hand: if
+ * each command depends on the previous one's result, it is a sequential script
+ * and a pipeline cannot help.
+ *
+ * The failure worth seeing is at the bottom. A command that fails inside a
+ * pipeline does not fail the pipeline — ioredis resolves the batch and reports
+ * the error per command — so a batch can look successful while having silently
+ * dropped a write.
+ */
+
+import {
+  createClient,
+  health,
+  pipelineValues,
+  runPipeline,
+  shutdown,
+} from "@oneunit/redis";
+import { REDIS_URL, exampleLogger, onFailure, release, run } from "./_setup.js";
+
+const KEY_PREFIX = "example:pipeline:";
+const BATCH_SIZE = 100;
+
+await run("pipeline", async () => {
+  const client = createClient({ url: REDIS_URL }, exampleLogger);
+  onFailure(() => shutdown(client, exampleLogger));
+
+  const healthResult = await health(client);
+  if (healthResult.status === "down") {
+    // Shut down before returning: ioredis retries in the background, so a
+    // client left open keeps the event loop alive and the script never exits.
+    console.log("Redis is not reachable, stopping here.");
+    console.log("Health:", healthResult);
+    await release();
+    return;
+  }
+
+  // --- 1. A write batch ---------------------------------------------------
+  // Every key is independent, so all of them can go in one round trip.
+  const writes = Array.from({ length: BATCH_SIZE }, (_, index) => ({
+    label: `set:${index}`,
+    run: (pipeline) => void pipeline.set(`${KEY_PREFIX}item:${index}`, index),
+  }));
+
+  const started = Date.now();
+  const writeResult = await runPipeline(client, writes, {
+    logger: exampleLogger,
+  });
+  console.log(
+    `Wrote ${writeResult.results.length} keys in ${writeResult.durationMs}ms ` +
+      `(${Date.now() - started}ms wall clock).`,
+  );
+
+  // `pipelineValues` is the convenience path when every command is expected to
+  // succeed. It throws rather than hand back a sparse array if any of them did
+  // not, so a failed write cannot be mistaken for a successful one.
+  const values = pipelineValues(writeResult.results);
+  console.log(`  all writes reported OK: ${values.every((v) => v === "OK")}`);
+
+  // --- 2. A read batch ----------------------------------------------------
+  // MSET/MSETNX aside, reads are the case pipelines are built for: a dashboard
+  // that renders 100 rows can fetch them all at once.
+  const reads = Array.from({ length: BATCH_SIZE }, (_, index) => ({
+    label: `get:${index}`,
+    run: (pipeline) => void pipeline.get(`${KEY_PREFIX}item:${index}`),
+  }));
+
+  const readResult = await runPipeline(client, reads, {
+    logger: exampleLogger,
+  });
+  const readValues = pipelineValues(readResult.results);
+  console.log(
+    `Read ${readValues.length} keys in ${readResult.durationMs}ms, ` +
+      `all present: ${readValues.every((v) => v !== null)}.`,
+  );
+
+  // --- 3. A batch where one command fails ---------------------------------
+  // INCR on a string key is a real Redis error: WRONGTYPE, not a connection
+  // problem. The batch still resolves, and every other command still runs.
+  await client.set(`${KEY_PREFIX}string`, "not-a-number");
+
+  const mixed = await runPipeline(
+    client,
+    [
+      {
+        label: "incr:string",
+        run: (pipeline) => void pipeline.incr(`${KEY_PREFIX}string`),
+      },
+      {
+        label: "set:fine",
+        run: (pipeline) => void pipeline.set(`${KEY_PREFIX}fine`, "1"),
+      },
+      {
+        label: "get:fine",
+        run: (pipeline) => void pipeline.get(`${KEY_PREFIX}fine`),
+      },
+    ],
+    { logger: exampleLogger },
+  );
+
+  console.log(
+    `\nMixed batch: ${mixed.failed} of ${mixed.results.length} failed.`,
+  );
+  for (const step of mixed.results) {
+    // The per-command error is the whole reason to use runPipeline over a bare
+    // `client.pipeline()`. Reading only the values here would show `null` for
+    // the failed INCR and look like a successful batch.
+    console.log(
+      `  ${step.error ? "FAIL" : " ok "} ${step.label}: ` +
+        (step.error ? step.error.message : JSON.stringify(step.value)),
+    );
+  }
+
+  // `throwOnError: true` is the strict alternative for batches where a partial
+  // write is not acceptable. It raises a PipelineCommandError carrying the
+  // per-step results, so the caller can see which command broke without
+  // re-running the batch.
+  try {
+    await runPipeline(
+      client,
+      [
+        {
+          label: "incr:string",
+          run: (pipeline) => void pipeline.incr(`${KEY_PREFIX}string`),
+        },
+      ],
+      { throwOnError: true },
+    );
+  } catch (error) {
+    console.log(`\nWith throwOnError: ${error.name}: ${error.message}`);
+  }
+
+  // --- 4. Clean up --------------------------------------------------------
+  const removals = Array.from({ length: BATCH_SIZE }, (_, index) => ({
+    label: `del:${index}`,
+    run: (pipeline) => void pipeline.del(`${KEY_PREFIX}item:${index}`),
+  }));
+  removals.push({
+    label: "del:string",
+    run: (pipeline) => void pipeline.del(`${KEY_PREFIX}string`),
+  });
+  removals.push({
+    label: "del:fine",
+    run: (pipeline) => void pipeline.del(`${KEY_PREFIX}fine`),
+  });
+
+  await runPipeline(client, removals, { logger: exampleLogger });
+  console.log(`\nCleaned up ${removals.length} keys.`);
+
+  await release();
+  console.log("Disconnected cleanly.");
+});

package/examples/pubsub.js

@@ -0,0 +1,101 @@
+/**
+ * Publish/subscribe.
+ *
+ *   npm run example:pubsub
+ *
+ * Environment:
+ *   REDIS_URL    connection URL (default redis://localhost:6379)
+ *   REDIS_SILENT set to "true" to suppress connection-event logging
+ *
+ * A Redis connection in subscriber mode can only issue subscribe-family commands,
+ * so pub/sub always needs two clients. `subscribe` and `psubscribe` are also
+ * fire-and-forget: Redis does not queue a message published before a subscriber
+ * is attached, which is why this example subscribes and waits for the
+ * subscription count to confirm before publishing anything.
+ */
+
+import { createClient, shutdown } from "@oneunit/redis";
+import {
+  REDIS_URL,
+  exampleLogger,
+  onFailure,
+  release,
+  run,
+  sleep,
+  within,
+} from "./_setup.js";
+
+const NOTIFICATIONS = "example:notifications";
+const ALERTS = "example:alerts";
+
+await run("pubsub", async () => {
+  // Two clients on purpose: one cannot both subscribe and publish. Each is
+  // registered the moment it exists, and release() closes in reverse order, so
+  // the subscriber goes first.
+  const publisher = createClient({ url: REDIS_URL }, exampleLogger);
+  onFailure(() => shutdown(publisher, exampleLogger));
+
+  const subscriber = createClient({ url: REDIS_URL }, exampleLogger);
+  onFailure(() => shutdown(subscriber, exampleLogger));
+
+  const received = [];
+
+  subscriber.on("message", (channel, message) => {
+    received.push({ channel, message });
+    console.log(`  [${channel}]`, message);
+  });
+
+  // subscribe() resolves with the number of channels this client is now
+  // attached to. That count is the confirmation we need: a client already in
+  // subscriber mode may not run `PUBSUB CHANNELS`, since only subscriber
+  // commands are permitted in that mode.
+  //
+  // The wait is bounded because subscribe() is a queued command. Against an
+  // unreachable server it never settles, and nothing else would notice.
+  const attached = await within(
+    subscriber.subscribe(NOTIFICATIONS, ALERTS),
+    5000,
+  );
+
+  if (attached !== 2) {
+    console.log(
+      attached === "timeout"
+        ? "Subscribe did not complete within 5s. Is Redis running?"
+        : `Expected to attach to 2 channels, attached to ${attached}.`,
+    );
+    await release();
+    return;
+  }
+
+  console.log(`Subscribed to ${attached} channels. Publishing...\n`);
+
+  await publisher.publish(
+    NOTIFICATIONS,
+    JSON.stringify({ type: "info", message: "Deploy finished" }),
+  );
+  await sleep(50);
+
+  await publisher.publish(
+    ALERTS,
+    JSON.stringify({ level: "warning", message: "High memory usage" }),
+  );
+  await sleep(50);
+
+  await publisher.publish(
+    NOTIFICATIONS,
+    JSON.stringify({ type: "info", message: "Second message" }),
+  );
+  await sleep(100);
+
+  console.log(`\nReceived ${received.length} of 3 published messages.`);
+
+  // unsubscribe() resolves with how many channels the client is *still*
+  // subscribed to, so 0 here means both channels were detached. A client that
+  // has been in subscriber mode cannot issue any other command afterwards, so
+  // unsubscribe before reusing it as a normal client.
+  const stillSubscribed = await subscriber.unsubscribe(NOTIFICATIONS, ALERTS);
+  console.log(`Unsubscribed; ${stillSubscribed} channel(s) still attached.`);
+
+  await release();
+  console.log("Disconnected cleanly.");
+});

package/examples/queue-worker.js

@@ -0,0 +1,189 @@
+/**
+ * BullMQ queue and worker.
+ *
+ *   npm run example:queue-worker
+ *
+ * Environment:
+ *   REDIS_URL    connection URL (default redis://localhost:6379)
+ *   REDIS_SILENT set to "true" to suppress connection-event logging
+ *
+ * Demonstrates the whole queue surface: `createQueue` applies job defaults,
+ * `createWorker` processes jobs with retries and backoff, and
+ * `attachQueueEvents` observes progress from a separate connection. One client
+ * serves all three, which works because `createClient` defaults
+ * `maxRetriesPerRequest` to null as BullMQ requires.
+ *
+ * `prefix` is per-call on all three factories and must match. `attachQueueEvents`
+ * inherits it from the queue when you do not pass one, so setting it on the
+ * queue and worker is enough.
+ *
+ * The script exits once the demo jobs settle. Press Ctrl+C to stop early; the
+ * signal handler closes everything in reverse order of creation.
+ */
+
+import {
+  createClient,
+  createQueue,
+  createWorker,
+  attachQueueEvents,
+  shutdown,
+} from "@oneunit/redis";
+import {
+  REDIS_URL,
+  exampleLogger,
+  isReady,
+  onFailure,
+  release,
+  run,
+} from "./_setup.js";
+
+const QUEUE_NAME = "example-demo-jobs";
+
+await run("queue-worker", async () => {
+  const client = createClient({ url: REDIS_URL }, exampleLogger);
+  onFailure(() => shutdown(client, exampleLogger));
+
+  // Job defaults from createQueue: 3 attempts with exponential backoff,
+  // keeping the last 100 completed and 1000 failed jobs. Retention matters
+  // because BullMQ keeps finished jobs in Redis until something removes them.
+  const queue = createQueue({ name: QUEUE_NAME, connection: client });
+  onFailure(() => queue.close());
+
+  // Events come from a separate listener with its own blocking connection, so
+  // they cannot interfere with the worker's polling.
+  const events = attachQueueEvents({ queue, logger: exampleLogger });
+  onFailure(() => events.close());
+
+  // Every readiness wait is bounded and rejection-tolerant. BullMQ polls Redis
+  // with commands that ioredis queues while reconnecting, so against an
+  // unreachable server these never settle and the script would hang
+  // indefinitely with BullMQ's reconnect loops still running.
+  if (!(await isReady(queue.waitUntilReady(), "Queue"))) {
+    return;
+  }
+
+  if (!(await isReady(events.waitUntilReady(), "Queue events"))) {
+    return;
+  }
+
+  const completed = [];
+  const failures = [];
+
+  // `concurrency` is optional. Omitting it leaves BullMQ's default of 1, which
+  // is deliberately not overridden by an explicit undefined.
+  const worker = createWorker({
+    name: QUEUE_NAME,
+    connection: client,
+    concurrency: 2,
+    processor: async (job) => {
+      console.log(
+        `  processing ${job.name} (attempt ${job.attemptsMade + 1}/${job.opts.attempts ?? 3})`,
+      );
+
+      await new Promise((resolve) => setTimeout(resolve, 50));
+
+      // One in four jobs fails, to show the retry and backoff path.
+      if (job.name === "report" && job.data.fail) {
+        throw new Error("report generation failed");
+      }
+
+      return { processed: true, jobId: job.id, name: job.name };
+    },
+  });
+
+  // Registered before the readiness wait, since a worker that is never ready
+  // still holds its blocking connection open.
+  onFailure(() => worker.close(true));
+
+  if (!(await isReady(worker.waitUntilReady(), "Worker"))) {
+    return;
+  }
+
+  // Track settlement per job so the script knows when the demo is finished.
+  const settled = new Map();
+  const markSettled = (jobId, outcome) => {
+    settled.set(jobId, outcome);
+  };
+
+  events.on("completed", ({ jobId, returnvalue }) => {
+    completed.push(jobId);
+    console.log(`  completed ${jobId} ->`, returnvalue);
+    markSettled(jobId, "completed");
+  });
+
+  events.on("failed", ({ jobId, failedReason }) => {
+    failures.push({ jobId, failedReason });
+    console.log(`  failed ${jobId} -> ${failedReason}`);
+    markSettled(jobId, "failed");
+  });
+
+  // Clear anything left by a previous run so the counts below are meaningful.
+  // Clear anything a previous run left behind. obliterate() refuses an
+  // active queue, hence force.
+  await queue.obliterate({ force: true }).catch(() => {});
+
+  console.log("Enqueuing jobs...\n");
+
+  const welcome = await queue.add("welcome", {
+    userId: "user-1",
+    message: "Welcome!",
+  });
+  const notification = await queue.add("notification", {
+    type: "email",
+    to: "user@example.com",
+  });
+  // Succeeds on the first attempt.
+  await queue.add("report", { format: "pdf" });
+  // Fails every attempt, so it exercises the full retry budget.
+  const doomed = await queue.add("report", { format: "csv", fail: true });
+
+  console.log(
+    `Enqueued 4 jobs (${welcome.id}, ${notification.id}, ${doomed.id}, +1).\n`,
+  );
+
+  // Wait for all four to reach a terminal state. Bounded, so a worker that
+  // never picks the jobs up cannot hang the script forever.
+  // Clear the loser of the race. A pending timer keeps the event loop alive, so
+  // leaving it armed would hold the process open for the full 20s even after
+  // every job has settled.
+  let deadline;
+  const allSettled = await Promise.race([
+    new Promise((resolve) => {
+      const check = setInterval(() => {
+        if (settled.size >= 4) {
+          clearInterval(check);
+          resolve(true);
+        }
+      }, 50);
+    }),
+    new Promise((resolve) => {
+      deadline = setTimeout(() => resolve(false), 20000);
+    }),
+  ]).finally(() => clearTimeout(deadline));
+
+  if (!allSettled) {
+    console.log("Timed out waiting for jobs to settle.");
+  }
+
+  const counts = await queue.getJobCounts();
+  console.log("\nQueue counts:", counts);
+  console.log(
+    `Completed: ${completed.length}, failed permanently: ${failures.length}`,
+  );
+
+  if (failures.length > 0) {
+    const attemptsMade = await queue
+      .getJob(doomed.id)
+      .then((job) => job?.attemptsMade);
+    console.log(
+      `The failing job was attempted ${attemptsMade} times before BullMQ gave up.`,
+    );
+  }
+
+  // Close in reverse order of creation: worker, events, queue, then the shared
+  // client. BullMQ closes its own blocking connections for the first three.
+  await worker.close();
+  await release();
+
+  console.log("\nClosed cleanly.");
+});