> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plato.ae/llms.txt
> Use this file to discover all available pages before exploring further.

# Queue And Redis

> BullMQ queues, printer isolation, persistence, and Redis modes.

# Queue And Redis

The driver uses Redis and BullMQ so print jobs survive process errors and printer outages.

## Per-Printer Queues

Each unique `ip_address:port` gets a dedicated `PrinterStore`.

For example:

```txt theme={null}
192.168.1.50:9100 -> pc-printer_192_168_1_50_9100
192.168.1.51:9100 -> pc-printer_192_168_1_51_9100
```

Each store owns:

* One BullMQ queue.
* One BullMQ worker.
* One queue events listener.
* One printer status cache.
* One socket lifecycle controller.

Worker concurrency is `1`, so one printer never receives two jobs at the same time. Different printers can process in parallel because each printer has its own worker.

## Printer Registry

Known printers are stored in the Redis set:

```txt theme={null}
pc-printer:printers
```

On startup, `restorePersistedStores()` reads the set, recreates stores, and retries failed jobs.

## Retry Behavior

Default queue options:

```json theme={null}
{
  "attempts": 2147483647,
  "backoff": {
    "type": "fixed",
    "delay": 5000
  },
  "removeOnComplete": true,
  "removeOnFail": false
}
```

This means:

* Completed jobs are removed.
* Failed jobs are retained.
* Failed jobs retry with fixed backoff.
* The default `maxAttempts` effectively retries forever.

## Scheduled Jobs

`POST /print` accepts `runAt`.

If `runAt` is in the future, the driver adds the job with a BullMQ delay. If a delayed job was created for a future schedule, recovery logic does not promote it early.

Accepted `runAt` forms:

* Millisecond timestamp number.
* Numeric string.
* Date string that `Date.parse()` can parse.

## Queue Status

`GET /queue-status` aggregates all known stores:

* `waiting`
* `active`
* `delayed`
* `failed`
* `completed`
* `totalPending`
* `isProcessing`

`totalPending` is `waiting + delayed` across all stores.

## Embedded Redis

Embedded mode starts Redis through `redis-memory-server`.

On Windows, the driver checks or downloads the requested Redis binary:

```txt theme={null}
redis-binaries/<version>/Redis-<version>-Windows-x64-msys2/redis-server.exe
```

The actual running Redis version is checked after startup. If the detected version does not equal `config.redis.version`, startup aborts.

## Disk Sync

When `redis.diskSync` is true, Redis starts with snapshot settings:

```txt theme={null}
--save <snapshotIntervalSec> 1
--appendonly no
--dir <app-root>
--dbfilename dump.rdb
```

On graceful shutdown, the driver attempts a Redis `SAVE`.

Use disk sync when you need queues and known printers to survive restarts.

## External Redis

External mode does not start or stop Redis. The driver uses:

```json theme={null}
{
  "mode": "external",
  "host": "127.0.0.1",
  "port": 6379,
  "db": 0,
  "username": "",
  "password": ""
}
```

Use external Redis when a store already has managed Redis or when multiple driver processes need shared queue state. Avoid pointing two active drivers at the same physical printers unless the operational model is explicit.