No actionable comments were generated in the recent review. 🎉

Summary by CodeRabbit

• Chores
  • Enhanced Redis Sentinel connection pool configuration for improved reliability
  • Restructured message broker transport configuration for better compatibility

Walkthrough

Adds a Redis Sentinel connection pool option to Django caching configuration and moves Kombu transport options into a nested connection_options structure in two places where KombuManager is initialized; no other control flow or public API signatures were changed.

Changes

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

This PR fixes two crash-causing regressions introduced by #1838 (Redis Sentinel HA support), both strictly gated behind the REDIS_SENTINEL_MODE code path, leaving standalone Redis mode entirely unaffected.

Changes:

• backend/utils/log_events.py and workers/log_consumer/tasks.py: transport_options (holding master_name for Sentinel) was previously passed as a top-level kwarg to socketio.KombuManager(), which does not accept it. The fix correctly nests it inside connection_options, which KombuManager does accept and forwards verbatim to kombu.Connection().
• backend/backend/settings/base.py: The Django CACHES Sentinel config was missing CONNECTION_POOL_CLASS: redis.sentinel.SentinelConnectionPool, which django_redis.client.SentinelClient.connect() validates at startup. Its absence caused an immediate crash in the backend, celery-beat, and worker-metrics pods.

All three changes are minimal, targeted, and correct. No new environment variables or dependencies are introduced.

Confidence Score: 5/5

• Safe to merge — all changes are isolated to the Sentinel HA code path and directly fix documented CrashLoopBackOff crashes.
• The three one-liner fixes are each well-understood: one corrects a Python library API misuse (KombuManager kwarg nesting), and one adds a required config key for django_redis Sentinel support. Both are strictly behind the REDIS_SENTINEL_MODE flag, so standalone Redis mode (the default in local dev) is completely unaffected. No migrations, no new env vars, no dependency changes.
• No files require special attention.

Important Files Changed

Sequence Diagram

sequenceDiagram
    participant Backend/Worker as Backend / Celery Worker
    participant KombuManager as socketio.KombuManager
    participant KombuConn as kombu.Connection
    participant Sentinel as Redis Sentinel
    participant RedisMaster as Redis Master

    Note over Backend/Worker: Sentinel mode: REDIS_SENTINEL_MODE=true

    Backend/Worker->>KombuManager: KombuManager(url="sentinel://...", connection_options={"transport_options": {"master_name": "mymaster"}})
    KombuManager->>KombuConn: kombu.Connection(url, **connection_options)
    KombuConn->>Sentinel: Discover master via master_name
    Sentinel-->>KombuConn: Redis Master address
    KombuConn->>RedisMaster: Connect

    Note over Backend/Worker: Django cache (CACHES)
    Backend/Worker->>Backend/Worker: SentinelClient.connect() validates CONNECTION_POOL_CLASS == SentinelConnectionPool ✓
    Backend/Worker->>Sentinel: Discover master
    Sentinel-->>Backend/Worker: Redis Master address
    Backend/Worker->>RedisMaster: Cache read/write

_{Last reviewed commit: 4568ca1}

Test Results

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@chandrasekharan-zipstack Have you tested this from local?

Not yet @johnyrahul , as discussed will get this to staging and attempt testing this locally in parallel