feat(kafkajs): instrument producer.sendBatch#8403
Conversation
Overall package sizeSelf size: 5.86 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.0.1 | 82.56 kB | 817.39 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
|
✨ Fix all issues with BitsAI or with Cursor
|
BenchmarksBenchmark execution time: 2026-05-23 07:17:45 Comparing candidate commit a3841e8 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 1495 metrics, 98 unstable metrics. |
681b6c4 to
9792e32
Compare
9858515 to
97dc21c
Compare
|
This is blocked on a fix to instanbuljs for generating the coverage properly. See istanbuljs/istanbuljs#845 |
|
A new linting rule just landed in |
This adds tracing, header injection, and DSM checkpoints for the kafkajs producer.sendBatch API, which was previously uninstrumented: calls produced no spans and propagated no trace or DSM context. One kafka.produce span per topicMessages[] entry matches what producer.send already emits for the single-topic case and mirrors how kafkajs implements send internally (producer/messageProducer.js delegates send to a single-entry sendBatch). Per-entry granularity keeps DSM checkpoints correct on multi-topic batches. The broker response is one aggregated array covering every topic, so the plugin's finish filters by ctx.topic before tagging kafka.messages.offsets; otherwise each per-topic span would carry every other topic's offsets. Fixes: #1711 Refs: #8468
The integration spec in `packages/datadog-plugin-kafkajs/test/index.spec.js` needs Docker Kafka and always connects the producer before sending, so the slow-path branch through `cluster.refreshMetadataIfNecessary().then(...)` and its `refreshMetadataIfNecessary`-missing fallback never ran outside that one CI flag. This adds an instrumentation-level spec that drives the boundary with a faked cluster, pinning the resolve / reject / missing arms of the slow path, the proactive and reactive `refreshHeaderSupport` disable, and the `producerStartCh.hasSubscribers` fast skip without spinning a broker. Refs: #8390
The instrumentation-level spec at `packages/datadog-instrumentations/test/kafkajs.spec.js` is matched by `test:instrumentations`'s `PLUGINS=kafkajs` glob, but no workflow runs it. Without a job, codecov sees no session for the producer-boundary slow path or the `refreshHeaderSupport` disable arms.
The previous instrumentation-level spec only exercised `producer.send`. The integration spec needs Docker Kafka, so the sendBatch boundary's empty-batch fast skip, non-array messages else arm, sync-throw catch, and `KafkaJSProtocolError UNKNOWN` disable branch stay uncovered without faked-cluster unit tests.
Two of the new sendBatch cases duplicate branches the existing spec already pins: 1. The `empty topicMessages` case hit the same length-0 fast skip as the `missing topicMessages` case from a different ternary arm whose true side every multi-entry test already exercises. 2. The `clusterId after refreshMetadataIfNecessary resolves` case re-ran `withClusterId`'s resolve arm through sendBatch when the send-side slow-path test already covers all three withClusterId arms and every fast-path sendBatch test wires the boundary through L116.
cec38d6 to
774b242
Compare
Summary
The kafkajs
producer.sendBatchAPI was uninstrumented — calls produced no spans, propagated no trace context, and emitted no DSM checkpoints. This adds tracing, header injection, and DSM checkpoints, modeled as onekafka.producespan pertopicMessages[]entry (mirrors whatproducer.sendalready emits for the single-topic case and how kafkajs decomposessendintosendBatchinternally).Fixes: #1711