Open petersilva opened 10 months ago
I think this defect means all the flakey_broker flow tests can fail randomly because the C consumer will lose messages when the broker goes away (closing down the connection discards messages received by the library but not yet passed to client ... this seems to happen in some flakey_broker tests.) ))
sample output from tests:
test 6 FAILURE: compare contents of downloaded_by_sub_amqp and cfile differ
disabling this test in flow tests until this issue is resolved. the c consumer is not going to be resilient to failures until this is addressed.
in working on #120, I noticed that the C consumer auto_acknowledges messages in the library, in contrast to the careful control of acks in the python3.
The no_ack refers to not requiring the client to acknowledge messages. Long ago, I think there was testing of using acknowledgement, and the code is still there in comments... so I guess it never worked. Should revisit at some point.
note that the consumer (aka cpump) isn't used anywhere for anything at the moment, so priority of fixing it is low.
So this means that when messageRateMax is set to force queueing on the broker, the library will greedily read all the messages, and the broker side queue will disappear regardless of whether the application has seen it yet.