a month ago
Hello Railway Support,
I'm experiencing a critical issue with Bull Queue job processing on Railway that appears to be platform-specific and related to certain queue names.
Issue Summary
Bull queues successfully connect to Railway Redis and jobs are enqueued, but processors never execute the jobs. Jobs remain permanently in "waiting" state despite processors being loaded and listening correctly.
Environment Details
Services: NestJS app + Railway Redis addon
Queue Library: Bull (via @nestjs/bull)
Node Version: 20.x
Deployment: Nixpacks
What Works
Redis connection established successfully Bull queue initialization completes Jobs enqueue without errors Processors load and initialize correctly All logs show "ready to process jobs"
What Fails
Jobs never move from "waiting" to "active" Processor methods never execute No job completion ever occurs
My Testing Results
I've tested multiple queue name variations:
Failed Queue Names:
test-processing (jobs stuck in waiting)video-processing (main app affected)
Configuration Tested:
// Bull Queue Setup
BullModule.registerQueue({
name: 'test-processing', // This name doesn't work
defaultJobOptions: { /* standard options */ }
})
// Processor Setup
@Processor('test-processing')
export class TestProcessor {
@Process('test-job')
async handleJob(job: Job) {
// This method never gets called
}
}
Could you please investigate if there are:
Platform-level restrictions on certain Redis key patterns?
Known compatibility issues with specific queue names?
Redis configuration limitations affecting Bull queue persistence?
The Railway Station case suggests this is a known platform quirk rather than an application code issue.
Additional Context
Same codebase works perfectly in local development
Issue only occurs on Railway deployment
Multiple queue libraries seem affected (RQ and Bull)
Problem persists across different service deployments
I'd appreciate any insights into Railway Redis behavior with queue naming conventions or any recommended workarounds.
Thank you for your assistance.
3 Replies
a month ago
Hey there! We've found the following might help you get unblocked faster:
If you find the answer from one of these, please let us know by solving the thread!
a month ago
The hyphen in the queue name might be the problem. Some systems interpret hyphens as operators or delimiters, which can cause the queue to fail silently. Try renaming your queue from test-processing to test_processing, and see if it helps.
The fact that the queue registers but then fails to process messages points to a "silent queue fail." This means the connection or registration process seems successful, but something is causing the message consumption to halt without throwing a visible error. I'd recommend adding some debug logs to the processor class:
@OnWorkerEvent('error')
onError(error: Error) {
console.log("Worker Error: ", error);
}
@OnWorkerEvent('stalled')
onStalled(jobId: string, prev: string) {
console.log(`Worker stalled: ${jobId}`);
}You can check all the available bullmq listeners on their documentation. Also, I assume you might be using redis-server installed locally on your local machine. Try to connect to the railway redis from your local machine and check if it works correctly or not. If the railway redis server works properly with your local build, then something is disrupting your worker in the deployed version. That might need additional debugging to find out.
a month ago
Thank you for all the responses, I tried renaming the queue and added logs, but still had the same issue. I decided to use BullMQ instead, which is working fine.
I will close this post since I figured a workaround.