Path
The way of one Pub/Sub message through a RustStream service: the streaming pull, the delivery, the handler, the reply and the ack.
The diagram as text
- Streaming pull the client leases the message → Pump task forwards into a channel of 16
- Pump task forwards into a channel of 16 → PubSubMessage attributes become headers, uncopied
- PubSubMessage attributes become headers, uncopied → Dispatch one loop, or workers
- Dispatch one loop, or workers → Decode from the message's data
- Decode from the message's data → Handler async fn under #[subscriber]
- Handler async fn under #[subscriber] → Reply encoded into a buffer it hands over
- Reply encoded into a buffer it hands over → PubSubPublisher awaits the message id
- PubSubPublisher awaits the message id → Settlement ack, nack or a held retry
- Settlement ack, nack or a held retry → Ack sent with the client's next batch
The client takes the message off the stream and starts its lease. The pump task wraps it in a
PubSubMessage without copying: the data stays the
client's buffer, and the attributes move into the headers. The ordering key becomes the
partition-key header, and the attempt count pubsub-delivery-attempt where the subscription
has a dead-letter policy.
The handler's reply is encoded into a buffer that becomes the outgoing message's data as it is, because the client keeps the bytes it publishes. The headers become attributes; a header that is not UTF-8 fails the publish, because an attribute is text. A key named for the publish becomes the message's ordering key, as Ordered delivery draws.
The publish returns once the service has assigned the message an id. A reply that fails to publish settles the delivery with a retry, so the message comes back.
The delivery settles after the reply. An ack leaves with the client's next batch of acknowledgements, within about 100 milliseconds. What each outcome becomes is on Settlement.