AshDispatch.Transports.InApp (AshDispatch v0.6.11)

View Source

In-app notification transport.

Creates in-app notifications immediately (synchronous).

Behavior

  1. Checks the preferences of the receipt's own recipient (AshDispatch.UserPreference.allows_receipt?/4)
  2. Creates the Notification record for this receipt
  3. Updates receipt status to :sent

Status Flow

pending  sent (success)
         failed (error)
         skipped (user opted out)

Example

receipt = %{
  content: %{
    title: "Order Created",
    message: "Your order #1234 is being processed",
    action_url: "/orders/1234",
    notification_type: :success
  }
}

InApp.deliver(receipt, context, channel, event_config)
# -> Creates Notification records
# -> Returns {:ok, updated_receipt}

Summary

Functions

Delivers an in-app notification.

The idempotency key for one in-app delivery.

Retry a failed in-app delivery directly from a stored receipt.

Functions

deliver(receipt, context, channel, event_config)

Delivers an in-app notification.

Parameters

  • receipt - DeliveryReceipt map
  • context - Event context
  • channel - Channel configuration
  • event_config - Event configuration

Returns

  • {:ok, updated_receipt} on success
  • {:error, reason} on failure

idempotency_key(channel, context, user_id)

@spec idempotency_key(map(), map(), String.t()) :: String.t()

The idempotency key for one in-app delivery.

Shape: event_id:resource_id:audience:user_id, or event_id:audience:user_id when no resource identifies the occurrence. The audience segment keeps a user who is reachable through two audiences (their own, plus admin) from being notified twice for one event.

resource_id is the identity of the occurrence, not of the recipient. Where it comes from:

  • the channel's idempotency_source, naming the key in data that says which occurrence this is — use it whenever data carries more than one record with an :id;
  • otherwise the first value in data carrying a binary :id, which is a heuristic: with several such values the winner is map iteration order.

An event that keys on the recipient can only ever be delivered once per recipient, for the lifetime of that recipient.

retry_from_receipt(receipt)

Retry a failed in-app delivery directly from a stored receipt.

In-app delivery is synchronous (DB write + PubSub broadcast), so we re-attempt the Notification.create directly rather than going through Oban.

Uses the receipt's stored content and idempotency_key to prevent duplicates.

Returns :ok on success or {:error, reason} on failure.