Redix

Redix automatically attempts to reconnect to the Redis server if the connection drops.

Error Handling

If a disconnection occurs while requests are pending, Redix functions return {:error, %Redix.ConnectionError{reason: :disconnected}}. The caller is responsible for retrying these requests.

Backoff Strategy

Redix uses an exponential backoff strategy for reconnection attempts:

1. The first attempt occurs after an interval defined by :backoff_initial.
2. Subsequent attempts increase the interval by a fixed factor of 1.5 (e.g., n * 1.5, n * 1.5 * 1.5, etc.).
3. To prevent the interval from growing indefinitely, use the :backoff_max option to cap the delay.

Tip: To simulate a constant reconnection interval (e.g., every 5 seconds), set both :backoff_initial and :backoff_max to the same value (e.g., 5_000).

# Example: Constant reconnection interval of 5 seconds
Redix.start_link(..., backoff_initial: 5_000, backoff_max: 5_000)

You can create a custom module to control how Redix events are logged or processed. A handler must implement a function (typically handle_event/4) that matches the Telemetry signature.

When handling Redix events, the event parameter will be one of the following:

• :disconnection: Triggered when a connection is lost. Metadata includes address and reason (an exception).
• :failed_connection: Triggered when a connection attempt fails. Metadata includes address and reason (an exception).
• :connection: Triggered on successful connection or reconnection. Metadata includes address.

defmodule MyApp.RedixTelemetryHandler do
  require Logger

  def handle_event([:redix, event], _measurements, metadata, _config) do
    case event do
      :disconnection ->
        human_reason = Exception.message(metadata.reason)
        Logger.warn("Disconnected from #{metadata.address}: #{human_reason}")

      :failed_connection ->
        human_reason = Exception.message(metadata.reason)
        Logger.warn("Failed to connect to #{metadata.address}: #{human_reason}")

      :connection ->
        Logger.debug("Connected/reconnected to #{metadata.address}")
    end
  end
end

If your application cannot function without Redis, you should use a combination of :sync_connect and :exit_on_disconnection to ensure your application's state remains consistent with the availability of Redis.

Recommended Pattern

1. Set sync_connect: true to ensure the application doesn't start without an initial connection.
2. Set exit_on_disconnection: true so the Redix process crashes if the connection is lost later.
3. Place the Redix process and its dependent services under a supervisor using a strategy like :rest_for_one. This ensures that if Redix crashes, the dependent services are also brought down, preventing the app from running in a broken state.

Example Supervision Tree:

# Define children where Redix and its dependents are isolated
isolated_children = [
  {Redix, sync_connect: true, exit_on_disconnection: true},
  MyApp.MyGenServer
]

# Use :rest_for_one so if Redix fails, MyGenServer is also restarted/stopped
isolated_supervisor = %{
  id: MyChildSupervisor,
  type: :supervisor,
  start: {Supervisor, :start_link, [isolated_children, [strategy: :rest_for_one]]},
}

# Main application tree
children = [
  MyApp.Child1,
  isolated_supervisor,
  MyApp.Child2
]

Supervisor.start_link(children, strategy: :one_for_one)

The Redix.PubSub.Connection manages Redis Pub/Sub subscriptions using a state machine. When a connection is lost, the handler enters a :disconnected state.

Key behaviors include:

• Automatic Resubscription: Upon successful reconnection, the connection automatically resubscribes to all previously active channels and patterns that still have active subscribers in memory.
• Subscriber Monitoring: The connection monitors the PIDs of subscribers. If a subscriber process goes down while the connection is disconnected, it is removed from the internal subscription list to prevent unnecessary resubscriptions upon reconnection.
• State Transitions: The connection transitions between :connected and :disconnected states. During disconnection, it uses an exponential backoff strategy (controlled by :backoff_initial, :backoff_max, and an internal exponent of 1.5) to attempt reconnections.
• Message Delivery: When a message is received from Redis, it is dispatched to the monitored subscriber PIDs via a message format: {:redix_pubsub, sender_pid, monitor_ref, kind, properties}.