v1.19 - #164
Merged
Merged
Conversation
Regenerate both clients from the qdrant `dev` branch and bump to 1.19.0. gRPC: memory placement (`Memory` enum on vector/index/quantization params, `PayloadStorageParams`), keyword prefix matching, `SliceCondition`, per-request IDF corpus, `Datatype::Turbo4`, `max_disk_usage_percent`, explicit no-stemming. The search/recommend/discover RPCs are marked deprecated upstream. REST: same feature set. Qdrant also dropped the eight deprecated search/recommend/discover endpoints from its OpenAPI spec (qdrant/qdrant#9982), so the generator no longer emits them, but the actix handlers still serve traffic. They are preserved by hand in `src/openapi/deprecated_*.ts` and marked `@deprecated` in `qdrant-client.ts`, matching the additive-only line the Rust and Go clients took for 1.19. Also: - Pin `openapi-typescript` back to 6.2.6. It was bumped to ^7.13.0 in #150 without regenerating; v7 emits `requestBody?: never`, which collapses `OpArgType` to `never` in `@qdrant/openapi-typescript-fetch@1.2.6` and breaks every call site. Later 6.x patches widen nullable `anyOf` fields such as `ScoredPoint.payload` to `unknown`. - Teach `generate_client_construction.ts` to skip semicolons inside doc comments; the rewritten `/readyz` description contains one and split an interface member in half. - Forward `payload` and `metadata` from `createCollection`/`recreateCollection` (`metadata` was missed in 1.18). - Cover the new API surface in the REST integration tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reverses the previous commit's decision to keep them alive by hand. Qdrant removed the eight endpoints from its OpenAPI spec in qdrant/qdrant#9982, and we follow the spec: the actix handlers still answer, but an endpoint that is not in the spec is not part of the client's contract. This breaks semver — the removal is agreed on for 1.19 rather than deferred to a major. Removed from `QdrantClient`: `search`, `searchBatch`, `searchPointGroups`, `recommend`, `recommendBatch`, `recommend_batch`, `recommendPointGroups`, `discoverPoints`, `discoverBatchPoints`. Their request types leave `Schemas` with them, since the generator no longer emits them. `src/openapi/deprecated_{schema,api_client}.ts` are deleted and `api-client.ts` and `types.ts` go back to consuming the generated output unchanged. The gRPC client is untouched: those RPCs are only marked deprecated upstream, so they are still generated and still work. Tests and the node-js-basic example move to `query`/`queryBatch`. The example's sample-output comments are refreshed against a real run — note `query` returns `{points: [...]}` where `search` returned a bare array. `search points filter` is dropped rather than migrated: it was identical to the existing `query nearest points`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The note added with the pin named `requestBody?: never` as the cause. It is
not: an absent request body infers harmlessly. The breakage comes from the
placeholder parameter slots (`query?: never`, `path?: never`) — an optional
`never` property has type `undefined`, and `OpArgType` intersects the slots,
so `{collection_name: string} & undefined` is `never`.
Measured against the v1.19 dev schema: 16 of 67 operations become `never` and
11 become `undefined`, not "every call site".
Upstream openapi-typescript-fetch 2.x already solved this with a `NonNever`
guard; with it all 67 operations resolve. Our fork is two years behind, and
exists for BigInt point ids that upstream lacks, so the way out is to port the
guard into the fork rather than migrate off it.
Separately, the 6.x type erosion starts exactly at 6.7.2, and it traces back to
Qdrant's own spec: 260 nullable fields are written as a bare `{nullable: true}`
anyOf branch, which carries no type and so renders as `unknown`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
#150 raised openapi-typescript from ^6.2.6 to ^7.13.0 without regenerating the client, so the incompatibility with @qdrant/openapi-typescript-fetch@1.2.6 went unnoticed until this release regenerated. Put the range back exactly as it was before that bump rather than hard-pinning: it is a dev dependency, the lockfile still resolves 6.2.6, and the generated output is unchanged. Also drop the notes this branch added to how_to_release.md, leaving it as it is on master. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`dev` moved while this branch was being prepared — qdrant/qdrant#10035 landed the cluster-wide quota API. Regenerating picks up: - REST `GET /quotas` and `PUT /quotas`, wrapped as `getQuotas` / `updateQuotas`, plus the `QuotaConfig`, `QuotaStatus`, `QuotaUsage`, `PeerQuotaUsage`, `QuotaExceeded` and `QuotaTelemetry` schemas, and `TelemetryData.quota`. - `max_disk_usage_percent` leaves `StrictModeConfig` — it is now cluster-wide on the quota config. The gRPC field is reserved and `max_resident_memory_percent` is deprecated there, with removal announced for 1.21. This branch had shipped the strict-mode field and asserted on it; both are updated. - `quota_internal.proto` is new and internal — `qdrant.proto` does not import it, and its name matches every other excluded internal proto — so it is added to the removal list in `generate-grpc-sources.sh`. Without that, the next codegen would emit a `quota_internal_pb.ts` we do not want. Both codegens are idempotent against dev@aa6c5d84, and the integration suites run green against the matching `qdrant/qdrant:dev` image. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
CI pins the image to v1.18.0 until 1.19 is published, and the whole `Qdrant v1.19 API` block targets API that server does not have. Half of it fails loudly there, but `memory`, `payload` and `params.idf` are accepted and silently ignored rather than rejected, so those tests failed as `expected undefined to match object` and `0.5288952 not to be 0.5288952` — noise that says nothing about the client. The gate probes `/quotas`, which shipped in the same release and answers 404 on older servers. Version comparison would not work: qdrant's `dev` branch reports `1.18.3-dev` while carrying the full 1.19 API, so a `semver.gte(…, '1.19.0')` check would skip the block exactly where it needs to run. Only a 404 counts as "old server" — anything else propagates, so an unreachable server still fails the run instead of quietly skipping it. Verified against all three: v1.18.0 skips the block (18 passed, 7 skipped), dev runs it (25 passed), and a stopped server aborts with ECONNREFUSED. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The pin to v1.18.0 was only there because 1.19 is not tagged yet, and it forced the suite to carry a release-shaped seam: a `/quotas` probe, a `describe.skipIf` and a separate "Qdrant v1.19 API" block whose tests were skipped on the very server CI ran. Point the script at `dev` instead — the client tracks that branch until the release is tagged, so it is the server the generated code actually matches — and fold the block back into the single `QdrantClient` suite. No probe, no skips, every test runs the same way. Collections renamed off the release too: `test_collection_v1_19` is now `test_collection_params` and `test_collection_v1_19_sparse` is `test_collection_sparse`. Ran through `integration-tests.sh` itself: 25 REST + 17 gRPC, none skipped. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
IvanPleshkov
commented
Aug 3, 2026
IvanPleshkov
marked this pull request as ready for review
August 3, 2026 13:40
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Regenerate both clients from the qdrant
devbranch and bump to 1.19.0.NOTE: there are deprecation removal in openapi schema. Removed in TS client API