Workers & Background Jobs
Process queues with BullMQ and Redis instead of blocking requests. This guide follows version 3.1.7 (03acdf712c).
For the long-running services, see Background Services.
Primitives
backend/erxes-api-shared/src/utils/mq-worker.ts provides sendWorkerQueue and createMQWorkerWithListeners; Redis comes from utils/redis.ts. Plugins start workers through meta handlers such as startImportExportWorker, startAutomations, and startPayments inside startPlugin.
There is no backend/plugins/*/src/worker* file in the checked revision; plugin-side queue wiring lives in meta and module code, not in a top-level worker directory.
Service workers
- Automations (
backend/services/automations/src/bullmq/):triggerWorker, action handlers,aiWorker, wired byinitMQWorkers.ts. - Logs (
backend/services/logs/src/bullmq/):eventLogWorker,activityLogWorker,segmentWorker.
Both services register in Redis and resolve tenant models per subdomain before processing.
Content social publishing (example)
backend/plugins/content_api/src/modules/cms/postiz/ shows the full pattern: service.ts validates input with Zod, checks permissions and tenant (deliveryTenantFilter), queues per-channel jobs with deterministic _id and fingerprint for idempotency, and worker.ts delivers through the Postiz bridge. The UI in frontend/plugins/content_ui/src/modules/cms/posts/postiz/ (PostizPublishSheet.tsx, PostizDeliveryList.tsx) validates, then lists deliveries.
Follow the same shape for new jobs: validate with Zod, enforce tenant and permission checks, make jobs idempotent, and surface delivery state in the UI.
