Skip to main content

group_id

group_id on the policy orders everything a position publishes within one group; a call's own step and the partition key win over it.

A FIFO queue delivers the messages of one group in the order they were sent, one group member at a time. Messages of different groups do not wait for each other. A group belongs to a position: a slot, a reply or a lifecycle hook. Every send from that position to a .fifo destination falls back to the group its policy fixed.

Three answers can be in play at once, and the most specific wins. The call's own group_id step comes first. The message's PARTITION_KEY_HEADER comes next, the spelling that travels unchanged to every other broker. The policy's group comes last, and a send that names none at all goes under "default". A FIFO delivery carries its group in the partition-key header, which is where a handler and a test read it.

A group on a position that publishes to a standard queue fails the publish with SqsError::NotFifo. A partition key alone is a portable hint, so a standard queue ignores it. SnsPublish::group_id does the same for a FIFO topic.

Example​

At startup the service replays the orders a previous run did not hand on, all in the group replay, so fulfillment receives them in the order they were taken. The place handler names each customer's group for its own messages, which wins over its slot's policy.

fn service(broker: SqsBroker) -> impl App {
RustStream::new(AppInfo::new("orders", "0.1.0")).with_broker(broker, |b| {
b.include(place).out(Placements, Publish::default()).build();
b.include(fulfil);
// The replay keeps its own order: every message the hook sends is in the group `replay`.
b.after_startup(
Publish::default().group_id("replay"),
async move |sqs| -> io::Result<()> {
for order in pending() {
sqs.message(&order)
.publish()
.await
.map_err(io::Error::other)?;
}
Ok(())
},
);
})
}