zvec

This is an optimizer regression in MSVC 19.51 (toolset 14.51.36231) on Windows 11 ARM64. It can occur when a loop containing static_cast<int>(codes[i]) * codes[i] is inlined into callers using constant-filled vectors under /O2 /Ob2.

Work around it by forcing 64-bit multiplication:

sum_squared += static_cast<int64_t>(codes[i]) * codes[i];

This preserves the result because the original 8-bit values cannot overflow a 32-bit product. Other workarounds are adding #pragma loop(no_vector) before the loop or splitting the loop into separate statements. The issue does not reproduce on MSVC 19.44.

This occurs in zvec 0.5.1 because src/ailego/CMakeLists.txt calls return() for MSVC on ARM64 before creating the zvec_ailego target, while BUILD_ZVEC_AILEGO_SHARED remains enabled. The issue is fixed by PR #352, merged into main.

Preferred fix: update your zvec dependency to the latest main or a release containing PR #352, then reconfigure:

rmdir /s /q build
cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=ON
cmake --build build

If you must stay on zvec 0.5.1 and do not need the all-in-one ailego shared library, disable it:

cmake -B build -G Ninja ^
  -DCMAKE_SYSTEM_NAME=Windows ^
  -DCMAKE_SYSTEM_PROCESSOR=ARM64 ^
  -DBUILD_C_BINDINGS=ON ^
  -DBUILD_ZVEC_AILEGO_SHARED=OFF

Alternatively, backport PR #352 or patch src/ailego/CMakeLists.txt: do not unconditionally return() for MSVC ARM64, keep the cc_library(NAME zvec_ailego ...) call, and apply GCC/Clang flags such as -march=armv8-a only for non-MSVC compilers.

The crash occurs because excludedFileTypes expands to thousands of file_id = ... OR ... predicates, and the native sqlengine::QueryNode parser recursively processes them until the stack overflows. This is fixed by pull request #694, which adds handling for long OR expressions and will be included in the next release. Upgrade @zvec/zvec, the Linux x64 bindings, and @zvec/zvec-grep once that release is available, for example: npm install @zvec/zvec@latest @zvec/bindings-linux-x64@latest @zvec/zvec-grep@latest. As a temporary workaround on affected versions such as @zvec/zvec@0.7.0 and @zvec/zvec-grep@0.2.1, omit excludedFileTypes from session.context() and filter excluded file types in JavaScript after retrieval, or reduce the number of files covered by the query.

This was a parameter propagation bug: IVFIndexParam::n_iters reached the IVF parameters but was not passed to the first-level KMeans/OptKMeans clusterer, so clustering used its default iteration count. Upgrade to a release containing the PR fix(core): IVF n_iters propagation to clusterer (issue #729), or cherry-pick that PR when building from source. The fix forwards n_iters into the first-level clustering parameters and includes regression coverage for builder parameter propagation.

This is a known index-rebuild bug in zvec 0.6.0 and 0.7.0. When optimize() removes superseded rows, the vector file is rebuilt using the live document count, but lookups still use the original segment row IDs. With K deleted/overwritten rows, the last K live vectors read past the end of the file, and later document IDs may also be mapped to the wrong vectors. Typical logs include Read vector failed, Failed to fetch vector, and vector indexer fetch failed.

Workaround on affected versions:
1. Do not call Collection.optimize() after performing upsert() updates or delete() operations.
2. If optimize() has already run, restore from a backup taken before optimization, or create a new collection with the same schema and re-upsert all live documents from your source data.
3. Upgrade to a zvec release containing the fix preserve vector row mapping when rebuilding indexes with deleted rows (the fix for issue #724). Use python -m pip install -U zvec, then confirm the release notes include that fix.
4. After upgrading, rebuild or re-import any collection previously corrupted by optimize(); upgrading alone may not repair an already incorrect vector mapping.

Verify recovery by checking both scalar results and fetch() with vectors included, because stats.doc_count and scalar scans can still report documents that are missing from vector search.