Class EddyqApp

Whether this app has a Postgres backend configured. Lets callers decide whether to call PG-only methods (migrate, enqueueBatch).

Whether this app has a Redis backend configured.

Interval-style schedule. Supported on both Postgres and Redis since the schedule_intervals migration landed.

Cancel a pending job. The caller must specify which provider owns the id — job ids are not globally unique across backends.

Ad-hoc retention sweep. The caller specifies which provider to clean — retention is a backend-local notion.

Close the Postgres pool (no-op when no PG backend).

Enqueue a job. The target backend is picked from options.queue via the route table — falling back to defaultProvider when the queue isn't in the table.

Bulk-enqueue with per-item routing. Items are grouped by their resolved provider (per options.queue → routes → defaultProvider), then dispatched to each backend in a single enqueueMany call. The returned counts are the sum across both backends.

Mixed batches across backends are supported in one call — useful for fan-in jobs where some children land on Redis (e.g. webhook delivery) and some on Postgres (e.g. ledger write).

Per-backend job-state snapshot. Same shape as the standalone Eddyq.getStats / EddyqRedis.getStats — just scoped to one backend so the dashboard can render each half independently.

Paginated job listing. Routes by filter.queue if set, otherwise uses the default provider. Pagination doesn't compose across two backends — callers wanting cross-backend results should issue two separate calls and stitch UI-side.

Per-backend listJobs. Same shape as the routed listJobs — just scoped to one backend so a dashboard can fetch each half and stitch results UI-side (sort by createdAt, sum the totals).

Per-backend named-queue listing. Dashboards typically render one list per backend (since queue names aren't globally unique across backends — they can collide deliberately or accidentally).

Apply pending Postgres migrations (no-op when no PG backend). Mirrors Eddyq.migrate so the Nest module can call it uniformly.

Migration status for the Postgres backend (no-op when no PG backend).

Which backend a queue routes to. Returns "postgres" or "redis" based on the routing table + defaultProvider. Useful when callers need to pick provider-specific paths (e.g. NestJS @InjectQueue handles dispatching admin calls correctly).

Register the abort-broadcast handler. lib.cjs uses this to fan out shutdown to in-flight AbortControllers. Stored on the EddyqApp itself — fired once at the start of shutdown(), before either inner backend drains, so handlers see the signal regardless of which backend they're running on.

Set worker concurrency on both backends.

Drain both runtimes. Mode and timeout apply to both in sequence.

Start both backends' worker runtimes. Tuning options apply to both.

Subscribe each backend's worker pool to the queues that route to it. The first time this is called the routes from connect() take effect; subsequent calls let runtime callers (e.g. NestJS dynamic queue registration) extend the subscribed set.

Reconcile the schedule list against one provider's backend. The declared entries are upserted, anything not in the list is deleted. Idempotent — safe to run on every boot. Useful when schedules are declared in module config and the caller wants to keep them in sync.

Register a handler for kind. The same handler is registered on every configured backend — only the backend that actually fetches a job of this kind (per its subscribeTo) will invoke it.

Construct + connect both backends. queues declares the routing table (queue name → "postgres" | "redis"). Unrouted queue names fall back to defaultProvider; if that's omitted, the only configured backend wins.