Architecture: How should BullMQ handle Redis connection failures on Railwa...

Documentation for Sessions

🏗️ Architecture: How should BullMQ handle Redis connection failures on Railwa...

Date: 2026-02-20
Time: 15:38:14 UTC
Session: gspace1-128.3
Agent: architecture
Confidence: 100%
Status: ✅ Documented

📋 Decision Context

Question:

How should BullMQ handle Redis connection failures on Railway without blocking NestJS bootstrap?

Task: Not specified

🎯 Decision Made

Chosen:

maxRetriesPerRequest:null + connectTimeout + waitWithTimeout wrapper + closeQueueObjects cleanup

Options Considered:

Infinite ioredis retries (default)
Bounded retryStrategy with maxRetriesPerRequest:3
maxRetriesPerRequest:null + connectTimeout + waitWithTimeout wrapper + closeQueueObjects cleanup

💭 Reasoning

BullMQ requires maxRetriesPerRequest:null because it uses blocking Redis commands (BRPOPLPUSH/XREADGROUP). Setting it to 3 broke the Worker — jobs enqueued but never consumed. The solution uses connectTimeout (10s) for TCP-level timeout, a Promise.race wrapper (15s) around waitUntilReady() to prevent onModuleInit from hanging, and proper cleanup of Queue/QueueEvents objects on failure to stop background ioredis reconnection loops.

📁 Files Involved

No files specified

🔗 Related

Decision ID: dev_1771601894551_1p7b6bw
Session: 128
Workspace: gspace1

Auto-generated by MCP Smart Consolidation