Jido.Signal.Ext.Dispatch (Jido Signal v2.2.2)

View Source

Dispatch extension for Jido Signals.

This extension provides the same functionality as the existing jido_dispatch field through the Signal extension system while maintaining full backward compatibility. It allows configuring how signals are routed and delivered to various destinations using configurable adapters.

Features

  • Same tuple format as existing jido_dispatch: {adapter, opts} or list of tuples
  • Reuses existing dispatch validation logic from Jido.Signal.Dispatch
  • CloudEvents-compliant serialization with attribute name "dispatch"
  • Full compatibility with all existing dispatch adapters

Supported Adapters

The extension supports all the same adapters as the existing jido_dispatch field:

  • :pid - Direct delivery to a specific process
  • :bus - Delivery to an event bus (implementation pending)
  • :named - Delivery to a named process
  • :pubsub - Delivery via PubSub mechanism
  • :logger - Log signals using Logger
  • :console - Print signals to console
  • :noop - No-op adapter for testing/development
  • :http - HTTP requests using :httpc
  • :webhook - Webhook delivery with signatures

Configuration

Each dispatch configuration is a tuple of {adapter_type, options} where:

  • adapter_type - One of the built-in adapter types or a custom module
  • options - Keyword list of options specific to the chosen adapter

Multiple dispatch configurations can be provided as a list to send signals to multiple destinations.

Usage

# Add dispatch extension to a signal
{:ok, signal} = Jido.Signal.put_extension(signal, "dispatch", 
  {:pid, [target: self()]}
)

# Multiple dispatch configs
{:ok, signal} = Jido.Signal.put_extension(signal, "dispatch", [
  {:logger, [level: :info]},
  {:pubsub, [topic: "events"]}
])

# Retrieve dispatch configuration
dispatch_config = Jido.Signal.get_extension(signal, "dispatch")

CloudEvents Serialization

When serialized, the dispatch configuration is converted to a CloudEvents-compliant attribute named "dispatch". The serialization preserves the exact tuple structure for round-trip compatibility.

Examples

# Single dispatch configuration
{:ok, signal} = Jido.Signal.put_extension(signal, "dispatch", 
  {:logger, [level: :debug]}
)

# HTTP dispatch with custom headers
{:ok, signal} = Jido.Signal.put_extension(signal, "dispatch",
  {:http, [
    url: "https://api.example.com/events",
    method: :post,
    headers: [{"x-api-key", "secret"}]
  ]}
)

# Webhook dispatch with signature
{:ok, signal} = Jido.Signal.put_extension(signal, "dispatch",
  {:webhook, [
    url: "https://hooks.example.com/webhook",
    secret: "webhook_secret"
  ]}
)

Summary

Functions

Validates dispatch configuration data using existing dispatch validation logic.

Functions

validate_data(data)

@spec validate_data(term()) :: {:ok, term()}
@spec validate_data(term()) :: {:ok, term()} | {:error, String.t()}

Validates dispatch configuration data using existing dispatch validation logic.

Delegates to Jido.Signal.Dispatch.validate_opts/1 to ensure the same validation behavior as the existing jido_dispatch field.

Parameters

  • data - The dispatch configuration to validate

Returns

{:ok, validated_data} if valid, {:error, reason} if invalid

Examples

iex> DispatchExt.validate_data({:logger, [level: :info]})
{:ok, {:logger, [level: :info]}}

iex> DispatchExt.validate_data({"invalid", []})
{:error, "Invalid dispatch configuration: invalid structure"}