Skip to content

Conversation

ansd
Copy link
Member

@ansd ansd commented Jul 16, 2024

The modified outcome has not been supported in RabbitMQ 3.13 and won't be supported in RabbitMQ 4.0.

Specifically, neither in 3.13 nor in 4.0 are any of the modified fields implemented correctly:

<field name="delivery-failed" type="boolean"/>
<field name="undeliverable-here" type="boolean"/>
<field name="message-annotations" type="fields"/>

However in 3.13, RabbitMQ pretends to support the modified outcome by including the modified outcome in the outcomes field of the Source. When the receiver settles with the modified outcome, RabbitMQ either requeues or discards the message depending on some specific modified field combinations.

To follow the principle of least surprise, RabbitMQ 4.0 will make it clear in the outcomes field of the Source in the replying Attach frame, that RabbitMQ won't support the modified outcome. If a receiver nevertheless settles with the modified outcome, RabbitMQ will close the session.

This is a breaking change in RabbitMQ 4.0.

RabbitMQ 3.13 already documents in
https://github.com/rabbitmq/rabbitmq-server/tree/v3.13.x/deps/rabbitmq_amqp1_0 that the modified outcome is unsupported.
The same should be documented in RabbitMQ 4.0.

The modified outcome has not been supported in RabbitMQ 3.13 and won't
be supported in RabbitMQ 4.0.

Specifically, neither in 3.13 nor in 4.0 are any of the modified fields
implemented correctly:
```
<field name="delivery-failed" type="boolean"/>
<field name="undeliverable-here" type="boolean"/>
<field name="message-annotations" type="fields"/>
```

However in 3.13, RabbitMQ pretends to support the modified outcome by
including the modified outcome in the `outcomes` field of the `Source`.
When the receiver settles with the modified outcome, RabbitMQ either
requeues or discards the message depending on some specific modified field
combinations.

To follow the principle of least surprise, RabbitMQ 4.0 will make it
clear in the `outcomes` field of the `Source` in the replying `Attach`
frame, that RabbitMQ won't support the modified outcome.
If a receiver nevertheless settles with the modified outcome, RabbitMQ
will close the session.

This is a breaking change in RabbitMQ 4.0.

RabbitMQ 3.13 already documents in
https://github.com/rabbitmq/rabbitmq-server/tree/v3.13.x/deps/rabbitmq_amqp1_0
that the modified outcome is unsupported.
The same should be documented in RabbitMQ 4.0.
@ansd ansd added this to the 4.0.0 milestone Jul 16, 2024
@ansd ansd requested a review from acogoluegnes July 16, 2024 16:36
@ansd
Copy link
Member Author

ansd commented Jul 17, 2024

After feedback from @kjnilsson and having read the full context in #6121 and #6292 and checking that the QPid client indeed still sends a modified outcome in certain scenarios, e.g. in https://github.com/apache/qpid-jms/blob/90eb60f59cb59b7b9ad8363ee8a843d6903b8e77/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsMessageConsumer.java#L464, it's better when RabbitMQ does not cut the connection.

@ansd ansd closed this Jul 17, 2024
@ansd ansd deleted the modified branch July 17, 2024 07:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant