Queue And Redis
The driver uses Redis and BullMQ so print jobs survive process errors and printer outages.Per-Printer Queues
Each uniqueip_address:port gets a dedicated PrinterStore.
For example:
- One BullMQ queue.
- One BullMQ worker.
- One queue events listener.
- One printer status cache.
- One socket lifecycle controller.
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:restorePersistedStores() reads the set, recreates stores, and retries failed jobs.
Retry Behavior
Default queue options:- Completed jobs are removed.
- Failed jobs are retained.
- Failed jobs retry with fixed backoff.
- The default
maxAttemptseffectively 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:
waitingactivedelayedfailedcompletedtotalPendingisProcessing
totalPending is waiting + delayed across all stores.
Embedded Redis
Embedded mode starts Redis throughredis-memory-server.
On Windows, the driver checks or downloads the requested Redis binary:
config.redis.version, startup aborts.
Disk Sync
Whenredis.diskSync is true, Redis starts with snapshot settings:
SAVE.
Use disk sync when you need queues and known printers to survive restarts.