Skip to main content

fans_out_to

fans_out_to names the queues an operator subscribed to a topic, so a test sees every queue the topic delivers to.

A queue the service subscribes itself, through subscribe_queue_to_topic, is known to the broker. A queue an operator subscribed in AWS is known only to AWS. The step names those queues on the policy, and they apply to every topic the position publishes to. In process the account subscribes them to the topic before the publish, as the operator did. A live test waits for the subscription of each named queue to handle its copy. A queue SNS refuses, such as a FIFO queue on a standard topic, fails the publish.

The step exists with the crate's testing feature, which a service enables in its [dev-dependencies]. The service builds the policy with the step under #[cfg(test)], which holds in the build of the tests beside its code. A production build neither has the step nor calls it. A test under tests/ builds the service without cfg(test). There the service gates the step on a feature of its own that enables ruststream-sqs-sns/testing, and the tests run with that feature.

Example​

The dependency line:

[dev-dependencies]
ruststream-sqs-sns = { version = "0.7", features = ["sns", "testing"] }

The operator subscribed billing to orders-events, and the test build of the policy says so.

examples/sqs_sns_fans_out_to.rs
/// The topic's policy. The test build names the queue the operator subscribed.
fn announcements() -> SnsPublish {
    let policy = SnsPublish::default();
    #[cfg(test)]
    let policy = policy.fans_out_to(["billing"]);
    policy
}

fn service(broker: SqsBroker) -> impl App {
    RustStream::new(AppInfo::new("orders", "0.1.0")).with_broker(broker, |b| {
        b.include(accept).out_reply(announcements());
        b.include(bill);
    })
}