Worker queue system fails - missing Redis db/TLS config causes no background jobs to execute #312

Closed
opened 2026-04-05 16:19:20 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @SRCchen on 11/4/2025

Describe the bug

Worker service's BullMQ queue system fails to initialize with Redis TLS, causing all background jobs (incident email notifications, monitor updates, alerts) to not execute. Worker shows "Adding job to the queue" but no jobs actually run.

To Reproduce

Steps to reproduce the behavior:

  1. Deploy OneUptime with Redis TLS enabled (e.g., AWS ElastiCache)
  2. Set environment variables: REDIS_DB=1, REDIS_TLS_CA=<aws-ca-cert>
  3. Create an incident with monitor attached and "Visible on Status Page" = Yes
  4. Check Worker logs - see "Adding job to the queue: Incident:SendNotificationToSubscribers"
  5. Wait 5+ minutes - no "Running Job" logs appear
  6. Check Redis: redis-cli SCAN 0 MATCH "*bull:Worker*" returns empty
  7. No incident email notifications received

Expected behavior

  • Worker should create BullMQ queues in Redis
  • Background jobs should execute every minute with "Running Job" logs
  • Incident email notifications should be sent to subscribers
  • Redis should contain bull:Worker:* queue data

Deployment Type

Self hosted (deployed on our server with Kubernetes )

Additional context

Root Cause: BullMQ uses hardcoded Redis connection params missing db and tls config, while other OneUptime components use Redis.getRedisOptions() with full config.

Test Evidence:

  • Worker default config: Queue created but no Redis data
  • Correct config (db1+TLS): Queue data created successfully
  • Other components work fine: telemetryAttributesKeys-* data exists in Redis

Proposed Fix: Make BullMQ use same Redis config as other components:

// In Queue.ts and QueueWorker.ts
connection: Redis.getRedisOptions()

Impact: All Worker background functionality broken - no emails, no monitoring updates, no certificate renewals, no data cleanup jobs.

Could the development team please confirm this issue and provide a solution? Thank you!

*Originally created by @SRCchen on 11/4/2025* ## **Describe the bug** Worker service's BullMQ queue system fails to initialize with Redis TLS, causing all background jobs (incident email notifications, monitor updates, alerts) to not execute. Worker shows "Adding job to the queue" but no jobs actually run. ## **To Reproduce** Steps to reproduce the behavior: 1. Deploy OneUptime with Redis TLS enabled (e.g., AWS ElastiCache) 2. Set environment variables: `REDIS_DB=1`, `REDIS_TLS_CA=<aws-ca-cert>` 3. Create an incident with monitor attached and "Visible on Status Page" = Yes 4. Check Worker logs - see "Adding job to the queue: Incident:SendNotificationToSubscribers" 5. Wait 5+ minutes - no "Running Job" logs appear 6. Check Redis: `redis-cli SCAN 0 MATCH "*bull:Worker*"` returns empty 7. No incident email notifications received ## **Expected behavior** - Worker should create BullMQ queues in Redis - Background jobs should execute every minute with "Running Job" logs - Incident email notifications should be sent to subscribers - Redis should contain `bull:Worker:*` queue data ## **Deployment Type** Self hosted (deployed on our server with Kubernetes ) ## **Additional context** **Root Cause**: BullMQ uses hardcoded Redis connection params missing `db` and `tls` config, while other OneUptime components use `Redis.getRedisOptions()` with full config. **Test Evidence**: - Worker default config: Queue created but no Redis data - Correct config (db1+TLS): Queue data created successfully - Other components work fine: `telemetryAttributesKeys-*` data exists in Redis **Proposed Fix**: Make BullMQ use same Redis config as other components: ```js // In Queue.ts and QueueWorker.ts connection: Redis.getRedisOptions() ``` **Impact**: All Worker background functionality broken - no emails, no monitoring updates, no certificate renewals, no data cleanup jobs. Could the development team please confirm this issue and provide a solution? Thank you!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#312