Description
The int_latency metric in stats (average time a message spends in the producer's internal queue before being sent) is computed incorrectly when message.timeout.ms=0 (infinite timeout), which is a common setting for idempotent/transactional producers.
The calculation base uses rkm_ts_timeout (enqueue time + timeout), but when the timeout is disabled, rkm_ts_timeout is set to INT64_MAX. Subtracting that from now underflows to a huge negative number, corrupting the rkb_avg_int_latency window and any downstream consumer of the int_latency stat (dashboards, alerting, etc.).
Fix and detailed before/after explanation here: #5335 — it switches the base from rkm_ts_timeout to rkm_ts_enq (enqueue time), which is well-defined regardless of timeout and yields the correct queue latency in both cases. The PR has been open since 2026-02-28 without review; filing this issue to make the underlying bug visible/trackable independently of the PR queue.
How to reproduce
- Configure a producer with
message.timeout.ms=0.
- Enable statistics via
statistics.interval.ms and register a stats callback (rd_kafka_conf_set_stats_cb), which receives the stats as a JSON-formatted string — this is the only interface librdkafka exposes for stats, regardless of language/API used.
- Observe
brokers.<broker>.int_latency in the emitted stats JSON — min/max/avg will show a huge negative number instead of a small positive latency in microseconds.
IMPORTANT: Always try to reproduce the issue on the latest released version (see https://github.com/confluentinc/librdkafka/releases), if it can't be reproduced on the latest version the issue has been fixed.
Checklist
Description
The
int_latencymetric instats(average time a message spends in the producer's internal queue before being sent) is computed incorrectly whenmessage.timeout.ms=0(infinite timeout), which is a common setting for idempotent/transactional producers.The calculation base uses
rkm_ts_timeout(enqueue time + timeout), but when the timeout is disabled,rkm_ts_timeoutis set toINT64_MAX. Subtracting that fromnowunderflows to a huge negative number, corrupting therkb_avg_int_latencywindow and any downstream consumer of theint_latencystat (dashboards, alerting, etc.).Fix and detailed before/after explanation here: #5335 — it switches the base from
rkm_ts_timeouttorkm_ts_enq(enqueue time), which is well-defined regardless of timeout and yields the correct queue latency in both cases. The PR has been open since 2026-02-28 without review; filing this issue to make the underlying bug visible/trackable independently of the PR queue.How to reproduce
message.timeout.ms=0.statistics.interval.msand register a stats callback (rd_kafka_conf_set_stats_cb), which receives the stats as a JSON-formatted string — this is the only interface librdkafka exposes for stats, regardless of language/API used.brokers.<broker>.int_latencyin the emitted stats JSON —min/max/avgwill show a huge negative number instead of a small positive latency in microseconds.IMPORTANT: Always try to reproduce the issue on the latest released version (see https://github.com/confluentinc/librdkafka/releases), if it can't be reproduced on the latest version the issue has been fixed.
Checklist
message.timeout.ms=0debug=..as necessary) from librdkafka: not applicable, purely a stats/metrics computation bug