Skip to main content

Path

The way of one stream entry through a RustStream service: the append, the group read, the delivery, the handler, the reply and the XACK.

The path of one stream entry that is answered, from the append to its acknowledgementXADDa _payload field and h: fieldsXREADGROUPup to 64 entries, on the read clientRedisMessagefields become payload and headersDispatchthe runtime's loop or its workersDecodethe payload into the handler's typeHandlerasync fn under #[subscriber]ReplyXADD on a pool connectionSettlementthe outcome decidesXACKon a pool connection
The diagram as text
  1. XADD a _payload field and h: fields → XREADGROUP up to 64 entries, on the read client
  2. XREADGROUP up to 64 entries, on the read client → RedisMessage fields become payload and headers
  3. RedisMessage fields become payload and headers → Dispatch the runtime's loop or its workers
  4. Dispatch the runtime's loop or its workers → Decode the payload into the handler's type
  5. Decode the payload into the handler's type → Handler async fn under #[subscriber]
  6. Handler async fn under #[subscriber] → Reply XADD on a pool connection
  7. Reply XADD on a pool connection → Settlement the outcome decides
  8. Settlement the outcome decides → XACK on a pool connection

A read returns up to 64 entries in one round trip, and the subscription hands them out one at a time before it reads again. A batch handler reads as many entries as its batch size instead. When the stream has nothing new, the read blocks for the subscription's block interval, five seconds by default.

Each entry becomes a RedisMessage: the _payload field is the payload, and each h: field a header. The runtime decodes the payload and calls the handler.

The reply is encoded and published with XADD on a pool connection, and the delivery settles after it. A list read and a Pub/Sub message take the same way from the delivery on, with the form's own settlement, which Settlement draws.