StrictModeConfig.maxDiskUsagePercent maps to a field that no longer exists.
Qdrant 1.19 replaced the per-collection disk ceiling with the global quota API. The REST schema dropped
max_disk_usage_percent outright, and the gRPC definition reserved field 22 with a comment saying what
used to be there. The vendored copies in this repository are now from v1.19.1, so the mapping is already
written around the absence, but the property is still public, still documented as enforcing a ceiling,
and still validated to be between 1 and 100.
What it does today depends on the server and nothing says so. Against 1.18 it is enforced. Against 1.19
the REST engine sends a field the server does not document, and the gRPC engine cannot send it at all.
A caller reading the KDoc has no way to learn that.
maxResidentMemoryPercent is the neighbouring case and a milder one: 1.19 deprecates it rather than
removing it, and the proto says removal is planned for 1.21.
This is a deprecation decision rather than a deletion. The property cannot be removed before a major, so
the work is to mark it deprecated, say in the KDoc which server versions honour it, point at the quota
API, and decide whether the REST engine should stop sending it to a server that has no field for it.
Related to #106, which is the quota API itself, but separable: this one is about what an existing public
property means now.
Exit criterion: maxDiskUsagePercent and maxResidentMemoryPercent are deprecated with a message naming
the Qdrant versions that honour them and the replacement, STABILITY.md records the deprecation, and the
behaviour of a collection configured with either against a 1.19 server is asserted rather than assumed.
StrictModeConfig.maxDiskUsagePercentmaps to a field that no longer exists.Qdrant 1.19 replaced the per-collection disk ceiling with the global quota API. The REST schema dropped
max_disk_usage_percentoutright, and the gRPC definition reserved field 22 with a comment saying whatused to be there. The vendored copies in this repository are now from v1.19.1, so the mapping is already
written around the absence, but the property is still public, still documented as enforcing a ceiling,
and still validated to be between 1 and 100.
What it does today depends on the server and nothing says so. Against 1.18 it is enforced. Against 1.19
the REST engine sends a field the server does not document, and the gRPC engine cannot send it at all.
A caller reading the KDoc has no way to learn that.
maxResidentMemoryPercentis the neighbouring case and a milder one: 1.19 deprecates it rather thanremoving it, and the proto says removal is planned for 1.21.
This is a deprecation decision rather than a deletion. The property cannot be removed before a major, so
the work is to mark it deprecated, say in the KDoc which server versions honour it, point at the quota
API, and decide whether the REST engine should stop sending it to a server that has no field for it.
Related to #106, which is the quota API itself, but separable: this one is about what an existing public
property means now.
Exit criterion:
maxDiskUsagePercentandmaxResidentMemoryPercentare deprecated with a message namingthe Qdrant versions that honour them and the replacement,
STABILITY.mdrecords the deprecation, and thebehaviour of a collection configured with either against a 1.19 server is asserted rather than assumed.