gistfile1.txt

Slave processes can only send confirms.
There is no way to tell that the message should be rejected. 
Slave processes react to discard by confirming message, because discard
is used for messages which were acked before enqueue
for example when delivered to a no-ack consumer.

Enqueue:

Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | enqueue     |            |
  |------------>|            |
  |             | confirm    |
  |             |----------->|
  | confirm     |            |
  |------------------------->|
  |             |            | -> confirm


Deliver to consumer with no-ack:

Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | discard     |            |
  |------------>|            |
  |             | confirm    |
  |             |----------->|
  | confirm     |            |
  |------------------------->|
  |             |            | -> confirm


Reject (e.g. on max-length):

Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | discard     |            |
  |------------>|            |
  |             | confirm    |
  |             |----------->|
  | reject      |            |
  |------------------------->|
  |             |            | -> reject


If we inject a failure:


Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | discard     |            |
  |------------>|            |
  |             | confirm    |
  |             |----------->|
  X             |            |
  X DOWN        |            |
  X------------>------------>|
                |            | -> confirm (there were no rejects from this queue)


Because slave process always confirms, if the master fails before reject gets
to the channel - the message will be confirmed. Even if it should be rejected.

The fix in e5fd6b64c2aa7f82cc0213bea18c909dfbd741d4 (7399b798f56f7fa9b9e5b19f71bc5d7ec9382494 for 3.7.)
makes sure that the master process sends a reject before it sends a discard.

There is still a chance that reject will be lost and discard will not, but
it's much less likely.

Most likely scenario:

Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | reject      |            |
  |------------------------->|
  |             |            |
  X             |            |
  X DOWN        |            |
  X------------>------------>|
                |            |
                | promote    |
                |--->|       |
                |    |       |
                |<---|       |
                |            |
                | reject     |
                |----------->| 
                |            |-> reject



There is still a possibility that reject will get lost, but distard won't, but
then we're dealing with partitions and data is still compromised.

Possible failure scenario:

Master         Slave     Channel
  |             |   publish  | <- publish
  |             |<-----------|
  |             |   publish  |
  |<-------------------------|
  |             |            |
  | reject      |            |
  |---------------------X    |
  |             |            |
  | discard     |            |
  |------------>|            |
  |             | confirm    |
  |             |----------->|
  |             |            |
  X             |            |
  X DOWN        |            |
  X------------>------------>|
                |            |-> confirm