You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Supervised index wrapper bypasses its documented gate #1118
cbm_mcp_index_run_supervised_path() directly invokes the private supervisor path, but its public header says it returns NULL when the kill switch is set or the process is not a supervisor host. Current production callers pre-gate it, while direct callers and tests can bypass the documented contract.
Found during review of the SVN auto-watch work in #1113.
Suggested fix
Enforce cbm_index_supervisor_should_wrap() inside the public wrapper and add direct tests for unmarked host, kill switch, spawn failure, contained failure response, and success.
Thanks for isolating the contract mismatch. This is a scoped 0.9.1-rc stability bug: the public supervised-index wrapper should enforce its own documented gate rather than rely on every caller to remember a precondition. The regression should call the wrapper directly for the unmarked-host and kill-switch cases before the implementation change, then cover spawn failure, contained failure, and success without changing the public contract.
Thank you for isolating the public-wrapper contract mismatch. I have no new direct-wrapper gate test or resolution to report; caller preconditions alone do not settle the documented wrapper behavior.
Activity
DeusData commentedon Jul 16, 2026
Thanks for isolating the contract mismatch. This is a scoped 0.9.1-rc stability bug: the public supervised-index wrapper should enforce its own documented gate rather than rely on every caller to remember a precondition. The regression should call the wrapper directly for the unmarked-host and kill-switch cases before the implementation change, then cover spawn failure, contained failure, and success without changing the public contract.
DeusData commentedon Oct 19, 2026
Thank you for isolating the public-wrapper contract mismatch. I have no new direct-wrapper gate test or resolution to report; caller preconditions alone do not settle the documented wrapper behavior.