v0.3.2

What's Changed

Fixed

• RedisTransport background clients: connection-resilience kwargs passed to the
  transport (socket_timeout, socket_connect_timeout, socket_keepalive,
  socket_keepalive_options, health_check_interval, retry_on_timeout,
  retry_on_error, max_connections, and the ssl_* options) are now forwarded
  to both long-lived background clients — the PEL reclaimer and the consumer-group
  monitor. Previously each created its client with no socket timeout or keepalive
  regardless of the transport's settings, so a silently dropped connection (e.g.
  cloud Redis failover or an idle-connection reaper) left its blocking reads hung
  indefinitely with no way to recover — and for the monitor, that hang struck
  during the very failover it exists to recover from. decode_responses remains
  pinned per client (False for the reclaimer's binary passthrough, True for the
  monitor's string commands) and cannot be overridden by callers.

Added

• RedisTransport: Exponential retry backoff for SDK-managed retries. New
  subscribe() options retry_backoff_multiplier (default 1.0 = the previous
  constant cadence), retry_backoff_max_ms (cap on the escalated delay), and
  retry_backoff_jitter (spread retries across a worker fleet to avoid a
  thundering herd). The PEL reclaimer now treats a failing message as due once it
  has been idle for retry_on_idle_ms * (retry_backoff_multiplier ** retry_count)
  (capped at retry_backoff_max_ms), so a repeatedly-failing message is retried
  progressively less often (e.g. 30s → 60s → 120s …), giving an overloaded
  downstream room to recover instead of being hammered on a fixed clock. Backoff
  is opt-in and fully backward compatible: the default multiplier=1.0 reproduces
  the existing fixed retry_on_idle_ms spacing exactly.

Installation

pip install eggai==0.3.2