background-jobs

Long-running jobs can hit stale connections. Wrap work in with_connection and consider verify! before heavy DB usage. This reduces “PG::ConnectionBad” noise during long maintenance tasks.

For long operations (imports, conversions), run work in a job and stream progress updates. The job emits broadcast_update_to so the UI updates live without polling.

Enqueueing jobs inside a transaction can create “ghost jobs” when the transaction rolls back. Use after_commit or after_create_commit to enqueue work only after the DB commit succeeds.

Recurring tasks like cleanup jobs, report generation, or cache warming need reliable scheduling. The sidekiq-scheduler gem extends Sidekiq with cron-like scheduling without requiring separate infrastructure like cron or Kubernetes CronJobs. I define s

I used a transactional outbox when I needed my database write and my event publish to succeed or fail together. In OutboxEvent model, I treated the outbox like a queue: a durable row per event, a dedupe_key for idempotency, and a ready scope that pull

Not all background job failures should be retried the same way. Transient failures like network timeouts benefit from exponential backoff, but bugs in code or invalid data should fail immediately after a few attempts. Sidekiq provides retry configurat