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

Feature requeset: setting message headers #372

Closed
norberto-e-888 opened this issue Jan 21, 2022 · 5 comments
Closed

Feature requeset: setting message headers #372

norberto-e-888 opened this issue Jan 21, 2022 · 5 comments

Comments

@norberto-e-888
Copy link

norberto-e-888 commented Jan 21, 2022

Hi,

At my company we have a use case for writing to the message headers to set the following properties:

'x-retry': counter of retries attempts
'x-retry-limit': limit number of retry attempts
'x-delay': number of milliseconds the message should be delayed

could I get some guidance on how this might be achieved using the underlying amqp client, so I can potentially contribute said functionality in case the core team is busy. It is quite urgent for us...

Thank you

@underfisk
Copy link
Contributor

@norberto-e-888 This could be achieved during the publish using headers property in message properties but our rabbitMQ module isn't forwarding that, i can provide this feature

@WonderPanda
Copy link
Collaborator

Thanks @underfisk for super fast turn around to help out norberto. This is available now in @golevelup/nestjs-rabbitmq@1.21.01.

Let us know if it accomplishes your goals

@norberto-e-888
Copy link
Author

Thanks a lot for the super fast support. There is just one thing I forgot to mention, our use case requires not only to set headers on publish but also on message re-queueing, meaning when we return and instance of Nack(true). Any ideas on how we might achieve this?

@underfisk
Copy link
Contributor

underfisk commented Jan 24, 2022

@norberto-e-888 After testing for a while it seems that the message that is consumed is simply forward but if you wish to customize the error behavior you can do that and provide your custom error handler using errorHandler property. If this doesn't help you i can test more in-depth but having a repro by then would be then also useful

@norberto-e-888
Copy link
Author

@underfisk Looking at the args of errorHandler it looks quite promising as it exposes the headers, I will experiment to see if these headers are read-only or if we can write to them. I will report back my results. Thanks again for all the help.

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

No branches or pull requests

3 participants