search

sroze / messenger-enqueue-transport

Uses Enqueue with Symfony's Messenger component.
MIT License
191 stars 55 forks source link

[Symfony][RabbitMQ] Enqueue null not working with Enveloppe #60

Open artandor opened 5 years ago

artandor commented 5 years ago

I followed this documentation because i wanted to test my producer on an API-platform route.

In my case, i want to run my tests in a Gitlab CI environement, which mean there is no real need in testing the connexion to my broker (RabbitMQ here). Therefore, i've followed this configuration : 

# app/config/config_test.yml

enqueue:
    default:
        transport: 'null:'
        client: ~

I get an error because the enveloppe is not a supported class of the NullTransport. I need the enveloppe to setup a routing key for rabbitmq.

Uncaught PHP Exception Enqueue\MessengerAdapter\Exception\MissingMessageMetadataSetterException: "Missing "setRoutingKey" setter for "routingKey" metadata key in "Enqueue\Null\NullMessage" class" at /srv/api/vendor/enqueue/messenger-adapter/QueueInteropTransport.php line 220

weaverryan commented 5 years ago

Hi @artandor!

Ok, so the problem is that you're setting the routingKey in the TransportConfiguration when you're sending one of your messages. This ultimately cases $message->setRoutingKey() to be called. But, when you switch to the null transport, you are switching to the NullMessage(), which does not have a setRoutingKey() method on it. It's tricky: I totally understand what you're trying to do. On the other hand, the library is kind of correct to say: "Hey! You're trying to use an option on your message that is not supported by this transport!".

I'm open to suggestions!

artandor commented 5 years ago

I guess the AMQP transport configuration lacks of abstraction, which ultimately lead to having a "setRoutingKey" method that is too specific too some transports. It is indeed not really linked to the NullMessage itself. But in the end, the NullMessage becomes buggy when it comes to functionnal testing, which, according to the documentation, was one of its usage.

The simpliest fix could be to add a "dispatch: boolean" in the enqueue conf, that hooks into the dispatch process to stop it before connecting to the amqp server. This way we could use the same DSN instead of enqueue://null and we wouldn't need to bring back the broker online.

weaverryan commented 5 years ago

The simpliest fix could be to add a "dispatch: boolean" in the enqueue conf, that hooks into the dispatch process to stop it before connecting to the amqp server.

That's an interesting idea. Is that something that's supported in Enqueue in general already? Or are you just thinking out loud. It occurred to me that this is not a problem specific to this library - but Enqueue in general: if you are using the Amqp transport and calling custom setter methods on the AmqpMessage, then if you globally switch to the NullTransport for testing, it would also explode in a very similar way. The best path may be to find out how this is recommended to be handled in Enqueue in general, and then make sure this library is properly supporting that option.

Cheers!