src/test/resources/README.md says the vendored OpenAPI document is pinned to Qdrant v1.18.2. The
file's own info.version says master. Those cannot both be true, and the one that is a lie is the one
a reader believes.
It matters because of what that file is for. QdrantContractTest validates every request body the REST
engine builds against it, so it is the thing standing between a Qdrant release that renames a field and
a Kdrant that silently sends the old spelling. A document taken from master validates against fields
that no released Qdrant has yet, which makes the check weaker in the one direction it exists to be
strong in: a body that only a development build accepts passes.
The fix is a process rather than a file. Pin the document to a released tag, name that tag in one place
rather than in prose that drifts from it, and make refreshing it part of what a release does instead of
something somebody remembers. 2.2.0 added a version matrix that already knows which Qdrant versions
are supported, so the pinned schema and the matrix's newest cell can be the same fact rather than two.
While in there: the contract test carries a count of the operations it covers, which was raised by hand
twice in 2.2.0. A count maintained by hand is a check that will one day be lowered to make a build
pass.
Exit criterion: the vendored document's info.version matches a released Qdrant tag, that tag is stated
in exactly one place in the repository, and a build fails when the pinned schema is older than the newest
version the compatibility matrix claims support for.
src/test/resources/README.mdsays the vendored OpenAPI document is pinned to Qdrantv1.18.2. Thefile's own
info.versionsaysmaster. Those cannot both be true, and the one that is a lie is the onea reader believes.
It matters because of what that file is for.
QdrantContractTestvalidates every request body the RESTengine builds against it, so it is the thing standing between a Qdrant release that renames a field and
a Kdrant that silently sends the old spelling. A document taken from
mastervalidates against fieldsthat no released Qdrant has yet, which makes the check weaker in the one direction it exists to be
strong in: a body that only a development build accepts passes.
The fix is a process rather than a file. Pin the document to a released tag, name that tag in one place
rather than in prose that drifts from it, and make refreshing it part of what a release does instead of
something somebody remembers.
2.2.0added a version matrix that already knows which Qdrant versionsare supported, so the pinned schema and the matrix's newest cell can be the same fact rather than two.
While in there: the contract test carries a count of the operations it covers, which was raised by hand
twice in
2.2.0. A count maintained by hand is a check that will one day be lowered to make a buildpass.
Exit criterion: the vendored document's
info.versionmatches a released Qdrant tag, that tag is statedin exactly one place in the repository, and a build fails when the pinned schema is older than the newest
version the compatibility matrix claims support for.