[MOD-17688] Add a relabelVector API

[nonirosenfeldredis]

Describe the changes in the pull request

Adds VecSimIndex_RelabelVector(index, old_label, new_label), which moves the vector(s) stored
under one label to another without re-inserting them.

The caller is RediSearch (MOD-17688). Updating a document assigns it a new doc-id, and today
every vector it owns is deleted and re-added even when the vector itself did not change — on
HNSW that is a graph insertion plus a tombstone the GC has to collect later. Moving the label
does the same job as bookkeeping.

Outcomes are reported as a status code rather than a boolean, because a caller acts on them
differently: OldLabelMissing and SameLabel mean there is nothing to do, NewLabelTaken is a
conflict the caller may be able to resolve, and Unsupported says this index type never
relabels, so the caller must fall back to delete + insert instead of treating it as a no-op.

Implemented for brute-force (single and multi), HNSW (single and multi), and tiered HNSW. The
tiered case is the involved one: a label can live in the flat buffer, in pending insert jobs, or
in the HNSW graph, so all three are asked before anything moves, and the pending jobs are
re-keyed together with their own copy of the label — executeInsertJob indexes under
job->label and then looks the job up by it, so a half-applied move either indexes under the
stale label or throws out of a worker thread.

Which issues this PR fixes

1. MOD-17688

Main objects this PR modified

1. VecSimIndexInterface::relabelVector — new virtual, defaulting to Unsupported
2. BruteForceIndex_Single/_Multi, HNSWIndex_Single/_Multi — implementations
3. TieredHNSWIndex::relabelVector — all three homes of a label, under both guards
4. VecSimRelabelCode — the outcome enum

Mark if applicable

• This PR introduces API changes
• This PR introduces serialization changes

Note on ordering

#1025 is a sibling of this branch, not a descendant — both branch from the same point on main.
Together they are what MOD-17688 needs on the RediSearch side; neither depends on the other to
build.

🤖 Generated with Claude Code

---

Note

Medium Risk
Tiered relabel touches concurrent ingestion (job map + dual-tier state) under new lock ordering; incorrect partial updates could break workers or query label reporting, though extensive tests mitigate this.

Overview
Adds VecSimIndex_RelabelVector and VecSimRelabelCode so callers can move vector(s) from one label to another by updating label bookkeeping only—no vector copy and, for HNSW, no graph changes. This is meant as a cheap alternative to delete-then-add when an external id changes (e.g. RediSearch MOD-17688).

API: New C entry point and VecSimIndexInterface::relabelVector with a default of VecSimRelabel_Unsupported for index types that do not implement it (e.g. SVS). Distinct codes cover missing source, occupied target, same label, success, and unsupported so callers can treat conflicts vs no-ops vs fallback to delete+insert.

Implementations: Brute-force single/multi re-key label maps and sync id→label. HNSW updates idToMetaData[].label and the label lookup under indexDataGuard, skips marked-deleted labels, and adds isLabelExists. Tiered HNSW coordinates flat buffer, labelToInsertJobs (map key and job->label), and HNSW under flat-then-main exclusive locks, with source/target checks across all three homes before any move.

Tests & benchmarks: Unit coverage for BF/HNSW/tiered (including ingestion races and reject ordering); microbenchmark RelabelLabel for BF, HNSW, and tiered indexes.

^{Reviewed by Cursor Bugbot for commit 1a23d0e. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1a23d0e. Configure here.}

[cursor]

HNSW relabel races with queries

Medium Severity

HNSWIndex::relabelVector writes idToMetaData[id].label under only indexDataGuard, but searches call getExternalLabel without that lock. ElementMetaData is #pragma pack(1), so the label store is not atomic. Concurrent search can observe a torn or stale label. Tiered relabel avoids this with an exclusive main guard; standalone HNSW does not.

 

^{Reviewed by Cursor Bugbot for commit 1a23d0e. Configure here.}

[nonirosenfeldredis]

Closing as a duplicate: this is the same work that landed in #1017, which is already merged to main.

I opened this in error. I had checked git branch -r --contains against a stale origin/main — the fetch had failed silently on a proxy — so the series looked unpushed when it was in fact upstream. Verified now: every relabel file (vec_sim_interface.h, hnsw_tiered.h, hnsw_single.h, brute_force_single.h, vec_sim_common.h) is byte-identical to main, and #1017 also carries the RelabelLabel benchmark and the brute-force / SVS coverage tests from this branch, so nothing here needs salvaging. git cherry still listed the commits as unmerged only because #1017 landed squashed.

#1025 now merges current main, so it carries both halves of what MOD-17688 needs on the RediSearch side.