Because debian:stable updated its version of librdkafka, the
fall-through conf mechanism was no longer needed. However, the two
confs were still being merged during the call to rd-kafka-conf. This
had the effect of overriding user-provided conf values with the
default values from the topic-conf pointer.
Here's how the tests were broken:
On older versions of librdkafka, the "auto.offset.reset" config
value was set through the topic-conf handle, not the conf
handle. So on older versions, the fall-through function would set
the "auto.offset.reset" config value in the topic-handle, and
rd-kafka-conf would merge the two confs before returning.
On newer versions, all config values are set through the conf
handle and the fall-through function is never called. However,
because rd-kafka-conf was still merging the two confs together,
the user supplied config value for "auto.offset.reset" was being
overwritten with the default value provided by the topic-conf
handle. This default value is "largest" and was overriding the
provided value of "earliest" in the unit-tests, causing no
messages to ever be consumed by the tests.
Because debian:stable updated its version of librdkafka, the fall-through conf mechanism was no longer needed. However, the two confs were still being merged during the call to rd-kafka-conf. This had the effect of overriding user-provided conf values with the default values from the topic-conf pointer.
Here's how the tests were broken:
On older versions of librdkafka, the "auto.offset.reset" config value was set through the topic-conf handle, not the conf handle. So on older versions, the fall-through function would set the "auto.offset.reset" config value in the topic-handle, and rd-kafka-conf would merge the two confs before returning.
On newer versions, all config values are set through the conf handle and the fall-through function is never called. However, because rd-kafka-conf was still merging the two confs together, the user supplied config value for "auto.offset.reset" was being overwritten with the default value provided by the topic-conf handle. This default value is "largest" and was overriding the provided value of "earliest" in the unit-tests, causing no messages to ever be consumed by the tests.