Codify SaaS Blog - Page 2
Code-first guides and deep dives on building B2B SaaS products, designing APIs, scaling web apps, and modernizing legacy software.
BullMQ Queue Backing Up on AWS Lambda — Why Serverless Doesn't Fit
Queue depth climbs steadily and never comes back down, no matter how many times you check whether jobs are actually being added faster than they're processed. They aren't. The real problem is that whatever's supposed to be pulling jobs off the queue only exists for a few seconds at a time, then disappears — because it's running inside a Lambda invocation, not as a real worker.
Redis "READONLY" Errors After Upstash Failover
Writes were working fine a moment ago. Then, right after an Upstash failover event, every write starts throwing 'READONLY You can't write against a read only replica' — against the exact same connection that was accepting writes seconds earlier. The client isn't confused. It's still talking to the node that used to be primary, and that node just got demoted.
BullMQ Dashboard (Bull Board) Not Accessible Behind Vercel
The dashboard works perfectly on localhost. Deploy the same route to Vercel, and it's either a flat 404 or a module resolution error naming a package that's clearly sitting in node_modules. Bull Board isn't broken. It's a persistent, stateful admin UI, and Vercel's serverless functions were never the right place to run one.
Redis Connection Drops on Railway During Deploys — Graceful Reconnection Guide
Every deploy produces the same brief flare of Redis connection errors in the logs, lasting a few seconds, then quiet again. Most of the time that's completely expected — the old instance terminating while the new one comes up — and the actual bug isn't that it happens, it's that your app isn't configured to shrug it off gracefully.
BullMQ Repeatable Jobs Duplicating After a Deployment Restart
The nightly digest email fires twice. The daily report generates itself two times over. Nothing about the job's logic changed, and it happens specifically after every deploy — because a repeatable job's schedule got recreated instead of updated, and now two schedules are quietly running the exact same job in parallel.
Redis "MaxRetriesPerRequestError" on Upstash — What Actually Causes It
BullMQ throws MaxRetriesPerRequestError against Upstash and it reads like a connection problem — like Redis is unreachable and ioredis has given up trying. It isn't. BullMQ requires a specific setting that has nothing to do with whether Upstash is actually reachable, and skipping it throws this exact error even against a perfectly healthy connection.
BullMQ Jobs Stuck in Waiting State on Render Background Workers
Jobs enqueue without any error. They sit in the waiting list. They stay there. No worker ever picks them up, and there's no exception anywhere to explain why — because the thing that's supposed to be watching the queue was never actually deployed as something capable of watching it.
BullMQ "Missing Lock for Job" Error in Multi-Instance Deployments
One worker instance, everything runs fine. Scale to three, and BullMQ starts throwing 'missing lock for job' the moment a job finishes — as if two workers grabbed the same job at once. Most of the time, they didn't. The job's lock simply expired while the worker was too busy to renew it, and BullMQ is reporting the expiration, not an actual collision.
BullMQ Jobs Not Processing on Railway — Private Network IPv6 Issue
The worker logs show a clean Redis connection. No errors, no crash, nothing in the logs suggesting a problem at all. And yet jobs pile up in the queue, never picked up, like a mailbox nobody's actually checking. It's not BullMQ, and it's not your processor function — it's a one-line IPv4-versus-IPv6 mismatch that Railway's private network exposes by default.
Prisma + Neon Serverless — Connection Reset Errors Under Load
The first request after a quiet stretch fails with a connection reset, and the exact same request succeeds a moment later without you changing anything. It's not a flaky database — Neon's compute scaled itself to zero while nobody was looking, and Prisma's query engine gave up waiting before the compute finished waking back up.
Prisma Cold Start Latency on AWS Lambda — Why Every Request Is Slow
Every request that lands on a fresh Lambda instance eats a multi-second penalty before Prisma even runs your query. It's not your query, and it's not a fluke of AWS — Prisma has real per-cold-start costs, and most projects are paying more of them than they need to by bundling a package far larger than the Lambda runtime actually requires.
Prisma Seed Script Not Running in CI/CD Pipeline
npx prisma db seed works fine on your machine, populates a fresh database with exactly the reference data you expect, and then silently does nothing — or fails outright — the moment the same pipeline step runs in CI. The seed script isn't broken. Something in the CI environment either can't run it at all, or nothing in the pipeline ever actually called it.