5.12.1 — 2026-10-14¶

Fixed¶

Consume span ends at the commit - The Kafka instrumentor opens a <topic> process span when a message is polled and ended it only on the next poll, consume or close. The span then covered idle time and stayed the current span of the thread, so unrelated spans became its children. KafkaConsumerAdapter.commit now ends it.
- batch_consume produces one span for the whole batch, with a link to every message; commit once after the batch
- A consumer that never commits, such as one with ENABLE_AUTO_COMMIT=true, keeps the previous behaviour
- The async consumer adapter is unchanged, because its polls run in an executor thread

Kafka consume spans - New scenarios cover a batch, one message at a time, consecutive polls without a commit and auto-commit, against the real Kafka container and the OpenTelemetry Collector.
Test isolation - The Kafka span scenarios no longer leave an open span that made a later scenario record a span despite a sample ratio of zero. ConfluentKafkaInstrumentor.uninstrument does not unwrap consume or close, so binding it again wrapped consume twice and one batch produced two consume spans, the first never ended. The test cleanup now unwraps them. Production binds the instrumentor once and is not affected.

Type checker - ty 0.0.87 reports narrowed field overrides in the SQLite and StarRocks configs, so those two fields carry a documented ty: ignore.
Kafka tutorial - Describes how consume spans end for batches, single messages and auto-commit.

Lock file and lower bounds - uv.lock is refreshed and the lower bounds follow it: async-lru>=2.4.0 (Keycloak, MinIO and ScyllaDB packages), boto3>=1.43.113 (MinIO package), and the development tools boto3-stubs>=1.43.113, pre-commit>=4.7.0 and ty>=0.0.87. Transitive updates: botocore 1.43.113, botocore-stubs 1.43.113, markdown 3.11.1, sentry-sdk 2.72.0, starlette 1.8.0, truststore 0.10.5, types-s3transfer 0.19.2 and wrapt 2.5.1.