Groups

A FIFO queue delivers each message group in order: while a group has a message in flight, its next message waits, and the other groups go on.

The diagram as text

1. FIFO queue orders.fifo: alice; 1 in flight; 2 waits; 3 waits; bob; 1 delivered; 2 queued; 3 queued; carol; 1 delivered; 2 queued
2. FIFO queue orders.fifo → Consumer: one ReceiveMessage gets bob 1 and carol 1, alice waits: receive
3. A repeat of a MessageDeduplicationId within five minutes is accepted and not delivered

Every send to a FIFO queue names a MessageGroupId. The messages of one group are delivered in the order they were sent. While a message of a group is in flight, the queue hands out no other message of that group. The group moves on once that message is deleted or its visibility timeout lapses. Different groups do not wait for each other, so the groups are the unit of parallel work.

Each send also carries a MessageDeduplicationId. A send that repeats an id within five minutes is accepted and not delivered. A queue with content-based deduplication derives the id from a SHA-256 hash of the body, and an id the send names takes precedence.

This crate picks the group of a publish from the most specific place that names one: the call's SqsPublishOptions, then the message's PARTITION_KEY_HEADER, then the group the policy fixed, then default. It always sends a deduplication id: the one the call names, or one unique to the process. So two sends of the same body are two messages unless the service names the same id for both. A group or deduplication id set for a standard queue is refused with SqsError::NotFifo. On delivery, the group arrives in PARTITION_KEY_HEADER, and Lanes keys the workers by it.

An SNS FIFO topic delivers only to FIFO queues, and the message keeps its group on the way, as Topics draws.

The behaviour is Amazon SQS's own (FIFO key terms, message group id, deduplication id).