the flow_maint.sh tests in fail because the the moth_api_producer.py publishes a singe message, but there is no consumer queue waiting for it. The script checks for a message in a queue being waited for, but it is never there (because no subscriber queue is bound such that it would keep the message.) so that test always fails.
The publish works fine. It's not a problem with sr3... it's the test that is not set up to ever pass.
sample
from the first message, one can see that it actually did publish the message, but the test checking the result does not see that. The way it checks is to look for messages queued using rabbitmqadmin:
posted_message_count="`rabbitmqadmin -H localhost -u bunnymaster -p ${adminpw} -f tsv list queues | awk 'BEGIN { t=0; }; ( NR > 1 ) { t+=$2; } END { print t; };'`"
printf "count of messages queued is: ${posted_message_count}\n\n"
so it's looking for all messages on the broker, yet no queue is configured such that it will get the posted message, so this test will always fail even with the code working perfectly.
the flow_maint.sh tests in fail because the the moth_api_producer.py publishes a singe message, but there is no consumer queue waiting for it. The script checks for a message in a queue being waited for, but it is never there (because no subscriber queue is bound such that it would keep the message.) so that test always fails.
The publish works fine. It's not a problem with sr3... it's the test that is not set up to ever pass. sample
from the first message, one can see that it actually did publish the message, but the test checking the result does not see that. The way it checks is to look for messages queued using rabbitmqadmin:
so it's looking for all messages on the broker, yet no queue is configured such that it will get the posted message, so this test will always fail even with the code working perfectly.