QDRANT_CONNECT_TIMEOUT_MS and QDRANT_REQUEST_TIMEOUT_MS configure upstream timeouts, defaulting to five seconds and three minutes. The gateway logs both values at startup.

With ASYNC_PAYLOAD_WRITES=true, eligible payload updates run in background tasks. ASYNC_WRITE_QUEUE limits concurrent tasks to 256 by default; further updates receive an error while all slots are occupied. Failed background writes are logged.

CI checks Rust dependencies for known advisories. A manual release dry run builds and scans the image and packages the Helm chart without logging into GHCR or publishing a tag.

The gateway now checks the authoritative document store before deleting. A missing ID returns HTTP 404 with "result": "not_found", matching Elasticsearch’s delete result vocabulary:

{
  "_index": "products",
  "_id": "missing",
  "_version": 1,
  "result": "not_found",
  "_shards": {
    "total": 1,
    "successful": 1,
    "failed": 0
  }
}

Bulk delete keeps Elasticsearch’s useful nuance: the item has status 404 and "result": "not_found", but it has no error object and the top-level errors flag remains false. Missing updates are different because they failed to apply; those still carry document_missing_exception and set errors to true.

The regression test exercises standalone and bulk missing deletes in both storage modes. The trade-off is one point lookup before each delete, including successful deletes. As with the update existence check, a concurrent writer can race between the lookup and delete; the gateway does not yet implement Elasticsearch sequence numbers or primary-term concurrency controls.

The gateway now checks existence before every partial update. Missing documents return HTTP 404 with Elasticsearch’s document_missing_exception shape:

{
  "error": {
    "type": "document_missing_exception",
    "reason": "[missing]: document missing",
    "index": "products",
    "shard": "0"
  },
  "status": 404
}

Bulk updates report the same item-level error and set the top-level errors flag to true. Requests with "doc_as_upsert": true remain explicit creation requests; they return HTTP 201, including as bulk item statuses.

The regression test runs the missing, bulk, and doc_as_upsert cases against mock Qdrant responses in both storage modes. This correctness check adds one point lookup to partial updates that previously avoided a read. It does not add support for scripted updates or the separate upsert document form, and the gateway still does not emulate Elasticsearch’s optimistic-concurrency or version counters.

The gateway now makes upstream timeouts visible and configurable, bounds background payload writes, and waits briefly when SQLite is busy instead of failing immediately. CI also checks Rust dependencies for known advisories and offers a manual release dry run that builds, scans, and packages without publishing.

The client contract is unchanged. Upgrade the gateway, keep the Elasticsearch endpoint, and tune the new settings only if your workload needs to.

That is exactly the sort of job a human does once, then forgets on a Friday afternoon.

Release Please now watches main and opens a release pull request when Conventional Commit messages add a feature or fix. The pull request updates the changelog and keeps the Rust and Helm versions together. Once it is reviewed and merged, Release Please creates the tag and GitHub release; the existing publish pipeline sees that tag and adds the container, chart package, SBOM, and attestation.

The useful part is the pause in the middle: automation prepares the release, but a person still gets to read it before anything ships.

That mismatch matters to clients. An application using the status code to select its not-found path could treat an absent document as a successful fetch, even though the response body said otherwise. The gateway now returns 404 while preserving the Elasticsearch-shaped body and X-Elastic-Product response header.

The regression test exercises both source-storage modes: _source embedded in the searchable Qdrant collection and the optional dedicated document projection. In each mode, an empty Qdrant lookup must produce the same result:

HTTP/1.1 404 Not Found
X-Elastic-Product: Elasticsearch

{"_index":"products","_id":"missing","found":false}

This change is deliberately narrow. It does not yet emulate Elasticsearch’s version, sequence-number, or primary-term behavior, and delete/update behavior for missing documents remains a separate compatibility surface.

Oversized requests now return HTTP 413 with Elasticsearch’s content_too_long_exception error type. The response names the active setting and its byte limit, so an operator can decide whether to batch more narrowly or deliberately change the deployment limit. Both the early gateway check and the streaming body collector use the same response shape; bulk routes identify MAX_BULK_BYTES, while other routes identify MAX_BODY_BYTES.

The regression test sets deliberately tiny limits and verifies the status, error type, setting name, and exact configured ceiling for a search request and a bulk request:

cargo test oversized_requests_return_413_with_the_active_limit
cargo test --all-targets --all-features
cargo clippy --all-targets --all-features -- -D warnings

This does not implement automatic retrying or request splitting. HTTP 413 is intentionally non-transient: clients should reduce the body size, and operators should raise a limit only after considering the gateway’s memory budget and concurrency.

Previously, the gateway wrote SQLite metadata before asking Qdrant to create anything. If Qdrant was unavailable, rejected the collection configuration, or failed while creating the optional document projection, the request returned an error but the gateway still considered the index present. Later index checks succeeded against metadata and document operations failed against a collection that did not exist.

Index creation now treats SQLite as the publication step. The gateway creates the sparse collection, optional document collection, and payload indexes first. Only after those operations succeed does it record the index metadata. If a later setup step or the metadata write fails, it makes a best-effort attempt to delete the collections created by that request. Cleanup failures are logged without hiding the original creation error.

A regression test runs against an in-process mock Qdrant. It accepts the primary collection, fails the document collection, and verifies both observable properties: the index is absent from SQLite and the primary collection receives a cleanup request.

To reproduce the verification:

cargo test failed_index_creation_is_not_published_and_cleans_up
cargo test --all-targets
cargo clippy --all-targets -- -D warnings

This is compensating cleanup rather than a distributed transaction. A process crash between Qdrant creation and SQLite publication can still leave an orphaned collection, and a Qdrant outage can prevent cleanup. Operators should still monitor unexpected collections and retain reconciliation or backup procedures for the metadata database. The change prevents failed requests from publishing unusable gateway metadata and preserves the original metadata when an attempt to recreate an existing index is rejected upstream.

SQLite stores index mappings, vector definitions, and aliases. With a typical ReadWriteOnce volume, two pods may be constrained to one node or the second pod may be unable to mount the volume. Giving each pod separate storage is worse: the replicas can disagree about which indices and aliases exist. Even a shared filesystem needs locking semantics suitable for SQLite, and concurrent index administration still crosses SQLite and Qdrant without a distributed transaction.

The chart now defaults to one replica. CI renders the Deployment and asserts that default, while the chart and production guides spell out the requirements before an operator overrides it. This does not reduce a working default deployment from two fault-independent replicas: the old defaults never provided that guarantee.

To reproduce the chart check:

helm lint deploy/helm/qdrant-es-gateway
helm template smoke deploy/helm/qdrant-es-gateway \
  --show-only templates/deployment.yaml | grep '^  replicas:'

The expected rendered value is replicas: 1.

This is a safer default, not horizontal-availability support. A production design that needs multiple gateway replicas should first move the small metadata catalog to a replicated control-plane store, or deliberately provide ReadWriteMany storage with verified SQLite locking and serialize index and alias changes externally. Qdrant replication protects document collections; it does not replicate the gateway’s SQLite catalog.

Routing now percent-decodes each segment independently. Decoding after splitting is important: %2F becomes part of the document ID rather than a new route separator. Invalid UTF-8 is rejected as a structured bad request instead of being replaced with lossy text.

The focused verification covers an ID containing an encoded slash, Unicode, and a space, plus a non-UTF-8 path:

cargo test path_segments_
cargo test --all-targets --all-features
cargo clippy --all-targets --all-features -- -D warnings

This is route-level compatibility, not a relaxation of index-name rules or an implementation of Elasticsearch’s full URL grammar. Reverse proxies must also preserve encoded slashes when forwarding requests; deployments should include one representative encoded ID in ingress smoke tests.