fix(vector-store): create payload indexes even when the collection exists - #1578

…ists (MemMachine#1578)

_create_native_collection wrapped create_collection and every
create_payload_index in one try and swallowed "already exists" for the whole
block. A collection that already existed therefore raised on the first call,
took the already-exists path, and was left with no payload indexes at all -
despite the docstring promising both were created idempotently.

Two creators are easy to arrive at. The guarding lock is keyed on the
AsyncQdrantClient object, so it serialises callers inside one process and
nothing across them; with MEMMACHINE_WORKERS above 1 each worker has its own
client and its own lock. A crash between the two calls leaves the same state.

The collection and the indexes now sit under separate guards, and each index
is created individually and tolerant of already-exists.

Verified against Qdrant 1.19 in testcontainers. Before the change,
test_indexes_are_created_when_the_collection_already_exists fails with an
empty payload_schema - not a missing index, none of the twelve. After it, both
new tests pass, along with the rest of the vector store suite: 293 unit and
142 integration.

Scope, checked rather than assumed: a filtered query on an unindexed
collection returns only the matching tenant's points, so what a missing
sys-partition_key index costs is the multitenant storage layout and query
speed, not isolation. Note also that only the already-exists path reproduces;
two clients creating simultaneously both succeed, which the second test pins.

The tests need a real server and are marked integration - local-mode Qdrant
ignores payload indexes, so the defect is invisible there and CI, which runs
with `-m "not integration"`, will not exercise them.

Claude-Session: https://claude.ai/code/session_01Nr9kacmpFVTTfkZRw6esxP

Co-authored-by: Claude Opus 5 <[email protected]>
(cherry picked from commit a2a1754)
Signed-off-by: Haiyan Wang <[email protected]>

…ists (port of #1578 to main) (#1681)

* fix(vector-store): create payload indexes even when the collection exists (#1578)

_create_native_collection wrapped create_collection and every
create_payload_index in one try and swallowed "already exists" for the whole
block. A collection that already existed therefore raised on the first call,
took the already-exists path, and was left with no payload indexes at all -
despite the docstring promising both were created idempotently.

Two creators are easy to arrive at. The guarding lock is keyed on the
AsyncQdrantClient object, so it serialises callers inside one process and
nothing across them; with MEMMACHINE_WORKERS above 1 each worker has its own
client and its own lock. A crash between the two calls leaves the same state.

The collection and the indexes now sit under separate guards, and each index
is created individually and tolerant of already-exists.

Verified against Qdrant 1.19 in testcontainers. Before the change,
test_indexes_are_created_when_the_collection_already_exists fails with an
empty payload_schema - not a missing index, none of the twelve. After it, both
new tests pass, along with the rest of the vector store suite: 293 unit and
142 integration.

Scope, checked rather than assumed: a filtered query on an unindexed
collection returns only the matching tenant's points, so what a missing
sys-partition_key index costs is the multitenant storage layout and query
speed, not isolation. Note also that only the already-exists path reproduces;
two clients creating simultaneously both succeed, which the second test pins.

The tests need a real server and are marked integration - local-mode Qdrant
ignores payload indexes, so the defect is invisible there and CI, which runs
with `-m "not integration"`, will not exercise them.

Claude-Session: https://claude.ai/code/session_01Nr9kacmpFVTTfkZRw6esxP

Co-authored-by: Claude Opus 5 <[email protected]>
(cherry picked from commit a2a1754)
Signed-off-by: Haiyan Wang <[email protected]>

* style: reformat an assert ruff 0.15.14 formats differently (speedkick) (#1592)

style: reformat an assert ruff 0.15.14 formats differently

`ruff format --check` fails on speedkick as it stands: the pinned ruff
(0.15.14, from the root pyproject the lint workflow reads its version
from) moves the message of a multi-line `assert` onto its own line, and
one assert in the Qdrant store tests predates that. No behavior change.

Every PR targeting speedkick inherits the red format check until this
lands, which is why it is on its own rather than folded into one of them.

Claude-Session: https://claude.ai/code/session_01NKmF9xNph9QH3ozNw3ZnJL

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
(cherry picked from commit c2d234b)
Signed-off-by: Haiyan Wang <[email protected]>

---------

Signed-off-by: Haiyan Wang <[email protected]>
Co-authored-by: Claude Opus 5 <[email protected]>
Co-authored-by: Edwin Yu <[email protected]>