Trait InterestOwnerSubscriber 

pub trait InterestOwnerSubscriber<N: Network = Ethereum>: EventSubscriber<N> {
    // Required methods
    fn add_interest_owner(
        &mut self,
        owner: HandlerId,
        interests: &[ReactiveInterest<N>],
    ) -> SubscriberOperation<'_, ()>;
    fn add_interest_owner_with_backfill(
        &mut self,
        owner: HandlerId,
        interests: &[ReactiveInterest<N>],
        backfill: SubscriberBackfill,
    ) -> SubscriberOperation<'_, ()>;
    fn remove_interest_owner(
        &mut self,
        owner: &HandlerId,
    ) -> SubscriberOperation<'_, Option<Vec<ReactiveInterest<N>>>>;
    fn owner_interests(
        &self,
        owner: &HandlerId,
    ) -> Option<&[ReactiveInterest<N>]>;

    // Provided methods
    fn upsert_interest_owners(
        &mut self,
        _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>,
    ) -> SubscriberOperation<'_, ()> { ... }
    fn replace_interest_owners(
        &mut self,
        _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>,
    ) -> SubscriberOperation<'_, ()> { ... }
    fn replace_interest_owners_with_global_backfill(
        &mut self,
        _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>,
        _backfill: SubscriberBackfill,
    ) -> SubscriberOperation<'_, ()> { ... }
    fn add_interest_owner_with_canonical_catchup(
        &mut self,
        _owner: HandlerId,
        _interests: &[ReactiveInterest<N>],
        _retained: BlockRef,
    ) -> SubscriberOperation<'_, ()> { ... }
}

Extension trait for subscribers that can add and remove handler-owned interests incrementally.

EventSubscriber::register_interests remains the full-replacement setup API. Implement this trait when a subscriber can preserve unrelated live sources and delivery state while one handler’s interests are added or removed. Implementations should make owner replacement continuity-safe: updating an owner’s interests must not silently discard delivery progress the previous interests had already established (the in-crate AlloySubscriber carries the owner’s prior delivery anchor over to changed filter shapes and automatically backfills the gap). Every mutating operation is also a commit boundary: returning Ok means the new desired state is authoritative, while errors or cancellation must preserve the previous state or reconcile before exposing the uncommitted change.

Required Methods

fn add_interest_owner( &mut self, owner: HandlerId, interests: &[ReactiveInterest<N>], ) -> SubscriberOperation<'_, ()>

Add or replace the interests owned by owner, awaiting the subscriber’s commit boundary.

Implementations must leave the previously committed owner state authoritative when the operation returns an error or is cancelled before completion.

Errors

The returned operation reports SubscriberError when the owner update cannot be validated or committed.

fn add_interest_owner_with_backfill( &mut self, owner: HandlerId, interests: &[ReactiveInterest<N>], backfill: SubscriberBackfill, ) -> SubscriberOperation<'_, ()>

Add or replace owner interests and schedule log backfill for that owner, awaiting the subscriber’s commit boundary.

Errors

The returned operation reports SubscriberError when the owner update or requested backfill cannot be validated or committed.

fn remove_interest_owner( &mut self, owner: &HandlerId, ) -> SubscriberOperation<'_, Option<Vec<ReactiveInterest<N>>>>

Remove one owner’s interests, preserving unrelated interests, and await acknowledgement that the removal committed.

On error the owner must remain authoritative, so the runtime handler is not removed while subscriber delivery may still target it.

Errors

The returned operation reports SubscriberError when the removal cannot be committed while preserving unrelated owners.

fn owner_interests(&self, owner: &HandlerId) -> Option<&[ReactiveInterest<N>]>

Borrow the interests currently owned by owner.

Provided Methods

fn upsert_interest_owners( &mut self, _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>, ) -> SubscriberOperation<'_, ()>

Atomically add or replace several owners in one desired-state revision.

Unrelated owners remain installed. Returning Ok(()) is one commit boundary for the complete set; an error or cancellation must leave the previously committed owner topology authoritative. Durable remote subscribers should override this method so bootstrap creates one service revision and one activation barrier rather than one barrier per owner.

Errors

The returned operation reports SubscriberError::Unsupported by default, or an implementation-specific validation or commit failure.

fn replace_interest_owners( &mut self, _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>, ) -> SubscriberOperation<'_, ()>

Atomically replace the complete engine-managed owner topology without requesting history.

This is the fresh-runtime bootstrap operation. Base/unowned interests, stale owners, queued delivery, and dedupe/source state from the prior topology must not survive a successful replacement. Errors and dropped futures leave the prior committed topology authoritative.

Errors

The returned operation reports SubscriberError::Unsupported by default, or an implementation-specific validation or commit failure.

fn replace_interest_owners_with_global_backfill( &mut self, _owners: Vec<(HandlerId, Vec<ReactiveInterest<N>>)>, _backfill: SubscriberBackfill, ) -> SubscriberOperation<'_, ()>

Atomically replace the complete owner set and schedule one global historical log backfill in the same desired-state revision.

This is the continuity-safe bootstrap operation for a runtime that has already processed canonical state while the subscriber’s owner state is new or may have been lost. Implementations must commit the complete owner topology and all required historical work together: returning an error or dropping the future must leave the previously committed state authoritative. The default is deliberately unsupported rather than a sequence of partially committed single-owner updates. Historical records must be delivered through canonical global routing (DeliveryAudience::All / DeliveryScope::CanonicalProgress), not as owner catch-up, so their effects participate in the normal rollback journal before the source certifies the cutover. Base/unowned interests are replaced by this complete engine-managed topology. Any owner absent from owners must be removed together with its queued owner-only work, which closes the crash window where a subscriber committed registration but the runtime process died before installing the corresponding handler.

Errors

The returned operation reports SubscriberError::Unsupported by default, or a backfill, validation, transport, or atomic-commit failure.

fn add_interest_owner_with_canonical_catchup( &mut self, _owner: HandlerId, _interests: &[ReactiveInterest<N>], _retained: BlockRef, ) -> SubscriberOperation<'_, ()>

Add a handler discovered at retained canonical block C without opening a gap while registration commits.

The subscriber must subscribe/adopt the new desired state first, then expose the new owner’s matching records from C as owner catch-up and expose C + 1 through the activation head as one globally ordered canonical catch-up over the complete active interest union. This split is deliberate: the runtime already has a rollback entry for C, while later blocks must run every handler and create normal canonical journal entries. Errors/cancellation preserve the prior committed topology. Implementations that cannot uphold this coordinated transaction must return Unsupported; emitting owner-only records past C is invalid.

Errors

The returned operation reports SubscriberError::Unsupported by default, or a canonical-anchor, transport, or atomic-commit failure.

Dyn Compatibility

This trait is dyn compatible.

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

Implementors

impl<P, N> InterestOwnerSubscriber<N> for AlloySubscriber<P, N>

where P: Provider<N> + Send + Sync, N: Network + 'static, N::HeaderResponse: Send + 'static,