Decaf Blog In-depth updates on Decaf software, tooling, and open-source experiments

go-elasticsearch v9.3.5 - BulkIndexer Routing Fix

3 min read

elastic/go-elasticsearch v9.3.5 was published on June 22, 2026 with one practical fix for esutil.BulkIndexer: empty routing values are no longer sent as a routing query parameter. For data teams that use the Go client to load events, documents, or derived records into Elasticsearch, this is a small release about cleaner bulk indexing requests and less surprising routing behavior.

The full release notes and downloads are on the GitHub release page.

BulkIndexer stops sending empty routing

The only change called out in v9.3.5 is an esutil bug fix: BulkIndexer now omits an empty routing query parameter. The release notes tie this to issue #1514 and commit f9640f0.

That is narrow, but it is still relevant to ingestion code. BulkIndexer sits in the write path for applications that batch documents before sending them to Elasticsearch. If a caller builds bulk items from upstream records, it is common for routing to be optional. Some records have a tenant, account, customer, or partition key. Others do not. Sending an empty routing parameter is different from not sending routing at all, and the client should not blur that distinction.

This release adjusts that behavior at the request boundary. When routing is empty, BulkIndexer leaves the query parameter out. The release notes do not describe changes to bulk payload formatting, retry behavior, flush intervals, worker coordination, or response parsing. Treat this as a targeted request construction fix.

Why it matters for ETL write paths

Bulk indexing is often the final step in an ETL or ELT path. A job reads source data, reshapes it, assigns document IDs, and writes a batch into an index. Routing can be part of that contract when a pipeline wants related documents to land together, or when a multi tenant workload depends on a stable routing key.

An empty routing value is the awkward case. It can come from a missing source field, a partial transform, or a generic helper that always sets a routing field even when the source record does not provide one. In that situation, the clean behavior is to omit routing. The server then handles the request as an unrouted document write.

The fix in v9.3.5 keeps optional routing optional. It reduces the chance that a data pipeline emits a request with a query parameter that has no useful value. That helps code review too. When request logs or traces show no routing parameter, an operator can read that as intentional absence rather than an empty string pushed through a client helper.

Operator impact is limited

This is not a broad client release. The notes do not mention API additions, generated endpoint changes, dependency updates, security fixes, or transport behavior. There is no prerelease flag on this GitHub release, and the tag is a normal v9 line release.

For platform teams, the main review point is any code that sets routing on BulkIndexer items. If the value may be empty, v9.3.5 changes the outgoing request by dropping that empty parameter. That should align with the usual expectation for optional routing, but it is still worth checking integration tests that assert exact request URLs or query strings.

Data engineers should also look at pipeline metrics around rejected bulk items, write retries, and shard placement if routing is part of the ingestion design. The release notes do not claim a server side behavior change, so there is no reason to expect index mappings, ingest pipelines, or document content to change from this client update alone.

Where to get it