Перейти к основному содержимому
Эта страница ещё не переведена

Ниже показан английский оригинал.

Replies

A reply answered on the request's inbox reports the reply-to header as where its address is read, and its channel carries no address.

A NATS request carries the inbox its answer goes to, and this crate hands it to the handler as the reply-to header. A reply that a transform sends to that inbox has a different address for every request. So the operation's reply reports the runtime expression $message.header#/reply-to as its address.location, and the reply channel's address is null. The channel keeps the mount site's subject as its name: the fallback for a request that named no inbox.

A reply to a fixed subject keeps that subject as its channel's address and reports no location. A reply published with JetStreamPublish reports none either, because a JetStream delivery's reply field is its acknowledgement inbox; a request is answered over Core NATS with Publish. The Request-reply pages show both sides of a request.

Example​

The transform answers on the inbox of each request, and the app mounts it with .out_reply(Publish).transform(ReplyTo). The operation receive_orders_quote reports $message.header#/reply-to, and the channel orders.quotes reports no address.

#[subscriber("orders.quote", reply("orders.quotes"))]
async fn quote(order: &Order) -> Quote {
Quote {
id: order.id,
cents: 1200,
}
}

/// Answers on the inbox the request named; a delivery that named none is answered on the mount
/// site's subject.
struct ReplyTo;

impl<Cx, Options> PublishTransform<ForReply<Cx>, Options> for ReplyTo {
type Destination = Names;

fn apply(
&self,
out: &mut Outgoing<'_>,
_options: &mut Option<Options>,
cx: &PublishContext<'_, Cx>,
) {
if let Some(inbox) = cx.headers().reply_to() {
out.set_name(inbox.to_owned());
}
}
}