MOD-15579 Report 0 shared SVS memory until first index attaches

[dor-forer]

Describe the changes in the pull request

VecSim_GetSharedMemory() returned the shared SVS thread-pool allocator's self-accounting baseline (~8 bytes) as soon as the singleton was constructed. The singleton is constructed at module init via VecSim_UpdateThreadPoolSize (RediSearch's workersThreadPool_CreatePool), so the baseline was reported even on deployments that never create an SVS index.

RediSearch folds VecSim_GetSharedMemory() into the FT.INFO vector_index_sz_mb field, so this surfaced as a nonzero vector-memory figure on indexes (or whole servers) with no vector index at all — see the discussion on RediSearch#9859.

This gates VecSimSVSThreadPoolImpl::getSharedAllocationSize() on has_attached_index_ (read under pool_mutex_) so it reports 0 until the first SVS index attaches, for both ways the singleton can be touched early:

• never constructed (no SVS index created, VecSim_UpdateThreadPoolSize never called), or
• constructed only to record a requested pool size at module init, with no SVS index attached yet.

Thread-spawn timing is unchanged — only the reported size changes — so there is no CONFIG SET WORKERS-vs-first-attach race. getAllocationSize() is a lockless atomic read, called under the existing pool_mutex_ with no nested locking.

ThreadPoolLazyInit now asserts the baseline is exactly 0 before any SVS index attaches.

Which issues this PR fixes

1. MOD-15579

Main objects this PR modified

1. src/VecSim/algorithms/svs/svs_utils.h — VecSimSVSThreadPoolImpl::getSharedAllocationSize()
2. tests/unit/test_svs.cpp — ThreadPoolLazyInit

Mark if applicable

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

🤖 Generated with Claude Code

---

Note

Low Risk
Reporting-only change to shared memory accounting; thread-pool behavior and allocation timing are unchanged.

Overview
VecSim_GetSharedMemory() (and RediSearch FT.INFO vector_index_sz_mb) no longer reports the shared SVS thread-pool allocator’s tiny baseline as soon as the pool singleton exists at module init.

VecSimSVSThreadPoolImpl::getSharedAllocationSize() now returns 0 until the first SVS index attaches (has_attached_index_, read under pool_mutex_), including when VecSim_UpdateThreadPoolSize only constructed the singleton to record a deferred size. Actual pool allocation and thread spawn timing are unchanged—only reporting.

ThreadPoolLazyInit expects shared memory 0 after resetForTest() clears has_attached_index_, before any index attaches.

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

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.09%. Comparing base (6468271) to head (d58302a).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #979   +/-   ##
=======================================
  Coverage   97.09%   97.09%           
=======================================
  Files         141      141           
  Lines        8160     8164    +4     
=======================================
+ Hits         7923     7927    +4     
  Misses        237      237           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.