Files
qdrant/docs/redoc
Andrey Vasnetsov c124db6905 Make deprecated on_disk_payload optional in the REST schema (#10020)
* Make deprecated `on_disk_payload` optional in the API schema

`CollectionParams::on_disk_payload` was the last place the deprecated flag was
still a bare bool, in both the REST schema and the gRPC `CollectionParams`
message. Clients generated from those schemas model it as a required bool, so
removing the field in a future version would break them.

Make it optional in both schemas while keeping it populated on every path that
builds `CollectionParams`, so responses and the persisted collection config
still carry a value and existing clients keep working until it is removed.

The gRPC change is wire-compatible: proto3 `optional` only adds a synthetic
oneof for presence tracking, the field number and wire type are unchanged. It
does change what an absent field means, though, so decode absent as `false` when
reading a remote peer's collection info -- peers that predate the change encode
a plain bool, which is omitted from the wire when false.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Keep gRPC `on_disk_payload` a plain bool

Adding proto3 `optional` would let a new client tell "unset" from `false`, but
it also changes what an absent field means. A pre-upgrade server encodes a plain
bool, which is omitted from the wire when false, so a client generated from the
new proto would decode `false` as "unset" -- and upgrading the client first is
the order we recommend.

gRPC does not need the change anyway: protobuf tolerates a missing field by
design, so a gRPC client does not break at runtime when we stop sending this
one. The breakage this addresses is on the REST side, where a generated model
with a required non-nullable bool fails to deserialize a response that omits the
field. JSON encodes `false` explicitly, so the REST schema change carries no
equivalent ambiguity.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-29 12:56:31 +02:00
..
2022-02-03 11:35:26 +01:00
2022-02-16 11:35:37 +01:00
2022-03-03 23:58:13 +01:00
2022-06-08 12:47:10 +02:00
2022-06-16 15:30:46 +02:00
2022-06-24 13:14:48 +02:00
2022-06-28 11:51:29 +02:00
2022-07-05 11:13:03 +02:00
2022-07-25 20:05:07 +02:00
2022-07-26 19:28:53 +02:00
2022-08-08 11:13:54 +02:00
2022-08-10 21:15:40 +02:00
2022-09-19 10:05:57 +02:00
2022-09-19 15:31:35 +02:00
2022-09-30 11:08:16 +02:00
2022-10-13 09:14:11 +02:00
2022-10-13 09:14:11 +02:00
2022-10-18 10:49:43 +02:00
2022-10-27 10:16:21 +02:00
2022-11-07 11:31:12 +01:00
2022-02-07 07:59:09 +01:00
2022-11-07 11:31:12 +01:00
2022-11-07 11:31:12 +01:00