mirror of
https://github.com/abhigyanpatwari/GitNexus.git
synced 2026-09-15 23:32:49 +00:00
803f0bed5f
* fix(lbug): probe-then-load FTS extension on Windows (#1690) The Windows skip-on-process.platform==='win32' guard in pool-adapter.ts hard-skipped loadFTSExtension() for every Windows host, even when the FTS extension binary was already present locally at ~/.lbdb/extension/<version>/win_amd64/fts/libfts.lbug_extension. That left BM25 silently degraded on Windows hosts that had a working extension on disk, with no error path — `gitnexus doctor` still reported FTS as available, but query returned 0 BM25 hits. This patch adds hasLocalWinFtsExtension() which probes ~/.lbdb/extension/*/win_amd64/fts/ before the Windows skip. When a binary is on disk we call loadFTSExtension(..., { policy: 'load-only' }); the crashing install path documented in #1199 / #1217 is never exercised at query time, and LadybugDB's version-specific resolution combined with the ExtensionManager's tryLoad try/catch handles stale or zero-byte sibling version dirs cleanly (no dlopen attempted on a stale binary). When no binary is on disk at all, we fall back to the upstream skip so install-time SIGSEGV continues to be avoided. Verified on Windows 10 + Node 22.19.0 + gitnexus 1.6.5 + @ladybugdb/core 0.16.1 with the FTS extension cached at 0.16.0: * BM25 timing goes from 0 → ~250-326ms on previously-zero queries * gitnexus context / impact / cypher unaffected * Adversarial-mixed-state run (real 0.16.0 binary + zero-byte stubs at 0.15.0, 0.16.1, 0.17.0): exits 0, no SIGSEGV, FTS resolves to the real 0.16.0 binary, BM25 returns real hits * Stub-only state at the resolution path (0.16.0, zero-byte): exits 0, emits "FTS extension unavailable; load-only policy: extension not pre-installed", FTS marked unavailable cleanly via markUnavailable in extension-loader.ts — no silent greenlight Closes #1690 * test(lbug): cover hasLocalWinFtsExtension probe + format pool-adapter - Export hasLocalWinFtsExtension and add lbug-pool-win-fts-probe.test.ts with 7 cases against a real tmpdir + os.homedir spy: * missing ~/.lbdb/extension dir -> false * extension root present but no version dirs -> false * one version dir with binary present -> true * zero-byte stub at probe path -> true (LOAD failure handled downstream) * multi-version with binary only in a non-first dir -> true * multi-version with no binary anywhere (Nix/Bazel/MDM tree) -> false * fs.readdir throws (EACCES) -> false The Windows conditional in doInitLbug / initLbugWithDb is intentionally not unit-isolated: it reduces to `probe ? load : true` over a fully constructed lbug.Database + Connection pool, which the test/integration/lbug-pool*.test.ts suites already exercise on the windows-latest CI matrix. - Apply prettier format to the fs.stat() call in pool-adapter.ts, resolving the quality/format CI failure surfaced by gitnexus/autofix. Addresses DoD §2.7 test-coverage blocker raised in the production- readiness review on #1692, and the dir-exists-no-file regression case raised on #1690. Refs #1690. --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> |
||
|---|---|---|
| .. | ||
| fixtures | ||
| helpers | ||
| integration | ||
| unit | ||
| utils | ||