Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interpret x-death header from AMQP 0.9.1 client #11043

Closed
wants to merge 2 commits into from

Conversation

ansd
Copy link
Member

@ansd ansd commented Apr 19, 2024

Fixes #10709

This commit fixes the following regression which worked in 3.12.x, but stopped working in 3.13.0 and 3.13.1:

AMQP 0.9.1 client    --publish-->
Q                    --dead-letter-->
DLQ                  --consume-->
AMQP 0.9.1 client (death count is now 1) --republish-same-message-with-headers-as-just-received-->
Q                    --dead-letter-->
DLQ                  --consume -->
AMQP 0.9.1 (death count is now 1, but should be 2)

The reason this behaviour stopped to work in 3.13.0 is that the broker won't specially interpret x-headers in general, and the x-death header specifically in this case anymore.

In other words, the new desired 3.13 behaviour with message containers is that "x-headers belong to the broker".

While this is correct, it does break client applications which depended on the previous use case.
One simple fix is that the client application does not re-publish with the x-death header, but instead sets its own custom count header to determine the number of times it retries.

This commit will only be packported to v3.13.x branch. In other words, 4.0 won't interpret x-headers as done in 3.13.0 and 3.13.1.

The reason we backport this commit to v3.13.x is that the Spring documentation expliclity recommends re-publishing the message with x-death header being set:
https://cloud.spring.io/spring-cloud-static/spring-cloud-stream-binder-rabbit/3.0.6.RELEASE/reference/html/spring-cloud-stream-binder-rabbit.html#_retry_with_the_rabbitmq_binder

Fixes #10709

This commit fixes the following regression which worked in 3.12.x, but
stopped working in 3.13.0 and 3.13.1:

```
AMQP 0.9.1 client    --publish-->
Q                    --dead-letter-->
DLQ                  --consume-->
AMQP 0.9.1 client (death count is now 1) --republish-same-message-with-headers-as-just-received-->
Q                    --dead-letter-->
DLQ                  --consume -->
AMQP 0.9.1 (death count is now 1, but should be 2)
```

The reason this behaviour stopped to work in 3.13.0 is that the broker
won't specially interpret x-headers in general, and the x-death header
specifically in this case anymore.

In other words, the new desired 3.13 behaviour with message containers
is that "x-headers belong to the broker".

While this is correct, it does break client applications which depended
on the previous use case.
One simple fix is that the client application does not re-publish with
the x-death header, but instead sets its own custom count header to
determine the number of times it retries.

This commit will only be packported to v3.13.x branch.
In other words, 4.0 won't interpret x-headers as done in 3.13.0 and
3.13.1.

The reason we backport this commit to v3.13.x is that the Spring
documentation expliclity recommends re-publishing the message with
x-death header being set:
https://cloud.spring.io/spring-cloud-static/spring-cloud-stream-binder-rabbit/3.0.6.RELEASE/reference/html/spring-cloud-stream-binder-rabbit.html#_retry_with_the_rabbitmq_binder
@ansd ansd added the bug label Apr 19, 2024
This commit partially reverts c697f29
Now, we we expect the right thing again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants