Trait TableSubscriber 

pub trait TableSubscriber:
    Send
    + Sync
    + 'static {
    // Required methods
    fn table(&self) -> &str;
    fn run(
        self: Box<Self>,
        rx: UnboundedReceiver<SubscriptionMessage>,
    ) -> Pin<Box<dyn Future<Output = ()> + Send>>;
}

Subscribe to row changes on a named table from a wasm application.

Why not just ps.subscribe(table).await in the guest?

The guest runs in a separate wasm sandbox with its own linear memory and no visibility into the host tokio runtime — there is no host reactor for guest-constructed futures to register wakers against, and the guest cannot hold a host broadcast::Receiver whose Sender lives host-side. Long-running subscription work has to be host-driven; the guest only awaits a channel the host hands it.

How this bridge works

The app provides a TableSubscriber implementation via RegistrationContext::table_subscribers. During app-loader drain, the host:

1. Calls ps.subscribe(subscriber.table()).await — receiver is host-allocated.
2. Creates an mpsc::UnboundedChannel pair (the mpsc is the safe-across-the-boundary primitive).
3. tokio::spawns a forwarder task on the host runtime that loops broadcast_rx.recv().await → mpsc_tx.send(). Both primitives live in host tokio.
4. tokio::spawns subscriber.run(mpsc_rx) on the host runtime. The loop body is guest-defined, but it only awaits on the host-allocated mpsc::UnboundedReceiver — no guest-side subscribe or broadcast-receive happens.

The result is symmetric with the publish path: publish goes guest → host via a WIT import; subscribe goes host → guest via an mpsc receiver handed in at run() time.

Required Methods

fn table(&self) -> &str

Name of the table to subscribe to (matches @table name in schema).

fn run( self: Box<Self>, rx: UnboundedReceiver<SubscriptionMessage>, ) -> Pin<Box<dyn Future<Output = ()> + Send>>

Long-running loop. rx carries every row change published to the table’s pubsub stream. Runs on the host tokio runtime; is host-driven on behalf of the guest.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors