Added support for before_consume option

[pkgodara]

Added support for before_consume option.

We have after_connect option available that is very helpful to set up exchanges or dead-letter queues easily.
We currently don't have a way to setup the queue, bind it to the exchange, and wait for some processes to finish before start consuming from the queue.
With before_consume, we can setup the queue so we don't lose messages while we are waiting for processes to finish.

[coveralls]

Pull Request Test Coverage Report for Build c5123d94e56fd399ae586d61c93aaa6ed2687267-PR-139

Details

• 9 of 11 (81.82%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.6%) to 92.857%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/broadway_rabbitmq/amqp_client.ex	8	10	80.0%

Totals
Change from base Build 26c15521c9b7c566b54fd05edbcba4176c838fed:	-0.6%
Covered Lines:	221
Relevant Lines:	238

---

💛 - Coveralls

[whatyouhide]

@pkgodara mh, I’m wondering if these two options should exist together or if before_consume would supersede after_connect in some way?

[pkgodara]

I’m wondering if these two options should exist together or if before_consume would supersede after_connect in some way?

@whatyouhide I beg to differ. To me, after_connect has a very clear use case, that would run setups before declaring queue itself. Mostly in RabbitMQ context.

before_consume is after the queues are setup already, and messages are coming to the queues. This one is for side-effects before we start to consume. I could even make this a Zero arity function, because I can't think of any case where it might need to even interact with RabbitMQ. This function is run only in the service context, where we are using Broadway, to run side-effects before consuming messages in a cleaner way.

[whatyouhide]

We currently don't have a way to setup the queue, bind it to the exchange

This is still doable via :after_connect, right?

This function is run only in the service context, where we are using Broadway, to run side-effects before consuming messages in a cleaner way.

Shouldn't this be done in a more application-specific way, for example by starting another process that does the setup before the Broadway pipeline starts? Sorry, I’m having trouble seeing what's the use case here 😬

[pkgodara]

This is still doable via :after_connect, right?

Yes you're right, queue can be setup in the after_connect too, and that should solve it.
Thank you.