Hello, Sprykees. I have totally weird behavior in ...
# help
h
Hello, Sprykees. I have totally weird behavior in my publish listeners. I'm still using Spryker
202009.0
. Previously everything was fine. My last task was to extend
product-discontinued
module to have store relation so product can be discontinued for one store only. As I introduced new
spy_product_discontinued_store
table, I created two new listeners, that publish or unpublish when there are changes in this store. This listeners doesn't extend core listeners. Locally everything work perfectly, but on staging it works time-to-time. Once it works, next time it fails with an error:
"errorMessage":"Message body is not valid"
. If I trigger listeners with
console event:trigger:listener
I have no problem, everything works fine. I have found this message in
EventQueueConsumer
and we have it, when listener or
EventEntityTransfer
is missing. But, as I see in rabbitMQ message, both
listenerClassName
and
transferClassName
are set and they definitely exist. And, as I said previously, it works randomly - sometimes works, sometimes - not. I have no idea how to debug it or what else I can do. Any ideas? Thank you in advance.
b
I think we had something like this before. MEssages looked fine in rabbitmq UI but when the consumer received them, the message body was empty. I actually found this by connecting my local instance to staging / production rabbitmq and then use xdebug. If I remember correctly, Restarting rabbitmq solved this, but we never found the root issue
h
Can you advice me how to debug it? I've found only how to debug listeners.
b
first you have to find the rabbitmq connection settings, and replace them with the ones of the staging instance. you find the correct settings in AWS -> Systems Manager -> Parameter Store and search for BROKER_
Also you have to be connected to staging vpn
I had to test / search around a bit to find the correct rabbitmq connection params in the local setup. So not sure anymore
then you should be able to receive messages from staging queue (maybe stop staging jenkins jobs before you start)
and then, locally, you can receive messages (--no-ack param to not remove them) from the queue and debug by executing: docker/sdk console -x queuetaskstart --no-ack <queue_name>
and set a breakpoint in the queue consumer of course, where you want to look into the message that is received to see what happens with it
h
Thank you, David, I'll try it.
✅ 1