Skip to main content
Subscribe to gateway channels and receive real-time messages — WebSocket first, polling when blocked.
The user subscribes to a channel; push events arrive over WebSocket and the agent summarises each message.
PushClient ships in the praisonai wrapper (pip install praisonai). Core praisonaiagents.push exports protocols and ChannelMessage only.

How It Works

Quick Start

1

Simple Usage

Connect and subscribe:
2

With Configuration

Enable push on the gateway:

How It Works

Import paths:

After fallback: producer contract

Polling is subscribe-only. After a WebSocket → polling fallback, publish(), create_channel(), and get_presence() raise NotImplementedError — the polling contract has no matching server routes. Gate producer code on PushClient.supports_publish before calling any of them.
supports_publish is True only when a transport is connected and is not the polling fallback. It is False before connect(), after disconnect(), and after a WS → polling fallback.
The polling fallback is durable by default when paired with a delivery store: a full per-client queue overflows to the store (at-least-once) instead of dropping, and pending events replay on the next poll. See Durable Polling for max_queue_size and the ack 503 compatibility note.
The client also emits a WARNING log the moment it falls back, so an operator watching the log knows publish is unavailable without instrumenting every call site:
Under polling fallback, PollingTransport.send({"type": "channel.publish", ...}) (and channel.create / presence.query) raises NotImplementedError instead of silently dropping the message (PR #3634).

HA & cross-instance delivery

With PushConfig(redis=...), multiple gateway instances fan out channel messages through Redis pub/sub so a subscriber on any instance receives every publish.

Self-healing on Redis outage

For the full outage lifecycle, health signals, and gateway doctor integration, see Redis Pub/Sub Resilience.
The fan-out adapter (RedisPubSubAdapter) survives a dropped Redis connection without operator intervention:
  • Bounded exponential backoff — reconnects starting at 1s, doubling on each failed attempt, capped at 30s. It never gives up unless the adapter is disconnected.
  • Automatic re-subscription — every channel is re-subscribed on the fresh pub/sub handle after reconnect, so operators do not re-subscribe.
  • Degraded surfacing — records itself as route:redis-pubsub in the degraded registry with a redacted reason and a retry_hint, so gateway status / gateway doctor / health()["degraded_owners"] show the outage.
  • Dropped-write countingpublish, set_presence, remove_presence, store_message, and delete_message calls made while disconnected are counted (previously silent no-ops) and exposed as dropped_writes.
  • Clears on recovery — the degraded record is removed and delivery resumes once Redis is reachable again.

What operators see

During an outage, gateway status reports the degraded transport under push and lists the owner in degraded_owners:
After recovery, the three redis_* fields return to healthy and the route:redis-pubsub entry is gone:
The reason only ever contains the exception message — the Redis connection URL and password are never surfaced. The log line to watch for on recovery is Redis push adapter reconnected (server_id=<uuid>).
Messages published while redis_degraded: true are counted in redis_dropped_writes and are not replayed on reconnect. If you need durable cross-instance delivery, publish from a source of truth you can replay.

Configuration Options

PushConfig

DeliveryConfig

PollingConfig


Best Practices

Without Redis, channels exist on one gateway instance only.
PushConfig(enabled=False) adds zero overhead — enable only when clients subscribe.
Set fallback_to_polling=True on PushClient when WebSocket is blocked — the client will still receive messages, but publish / create-channel / presence-query become unavailable. Check client.supports_publish before producer calls.
Real-time channels differ from A2A task webhooks — use the right page for your pattern.
A non-zero push.redis_dropped_writes after an outage tells you how many events fanned out one-sided. Alert on it if replay matters — those writes are gone from the cross-instance transport’s perspective.
The degraded_owners entry for route:redis-pubsub is the single place to hook a pager for cross-instance-transport outages. It appears for the duration of the outage and clears automatically on reconnect.

Gateway

Host push channels on the gateway

A2A Push Notifications

Webhook-based task updates

Durable Polling

At-least-once delivery for the long-poll fallback

Redis Pub/Sub Resilience

Multi-instance transport reconnect and outage surfacing