fix: track backend label separately in JSONL search handler (#14)

[alpurkan17]

Summary

State asymmetry between MCP and JSONL transports. When FTS5 returns no results and substring fallback returns results, the JSONL server mislabels them as backend: "fts5" instead of backend: "substring".

Root cause

_h_search used Python or to chain backends, then inferred the label from truthiness. When FTS5 returns [] (falsy), or evaluates the right side, hits becomes truthy, and the label becomes "fts5" — wrong.

Fix

Separate the FTS5 call, check result, fall through if empty — matching the correct pattern already used in server.py:82-93.

Related Issues

Closes #14

Summary by CodeRabbit

• Refactor
  • Improved search fallback logic to enhance reliability when full-text search results are unavailable.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 54e6cc7d-fb0f-4ef3-8665-97d4f8b1787d

📥 Commits

Reviewing files that changed from the base of the PR and between 89172aa and 9a7999d.

📒 Files selected for processing (1)

• src/vouch/jsonl_server.py

---

📝 Walkthrough

Walkthrough

The PR fixes a bug in the JSONL search handler where substring results were incorrectly labeled as FTS5 results. The fix separates the search fallback chain into sequential steps and explicitly tracks which backend was used, aligning the implementation with the correct pattern already used in the MCP server.

Changes

Search backend fallback logic

Layer / File(s)	Summary
FTS5 fallback backend tracking src/vouch/jsonl_server.py	The _h_search handler now runs FTS5 search first and sets backend to "fts5", then explicitly checks if hits are falsy and falls back to search_substring while updating backend to "substring" when the fallback is triggered, instead of inferring backend from truthiness after a chained or expression.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

A rabbit hops through search results bright,
Tracing which path led to the light—
Was it FTS5's ranking, true and fine,
Or substring's humble, straightforward line?
Now labels match the journey taken right! 🐰✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main fix: tracking backend labels separately in the JSONL search handler, matching the core change in the PR.
Linked Issues check	✅ Passed	The PR implements the recommended fix for issue #14 by replacing the or-based chaining with explicit separate calls and conditional fallthrough, correctly tracking backend labels.
Out of Scope Changes check	✅ Passed	All changes are scoped to the specific bug fix in jsonl_server.py; no unrelated modifications are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[plind-junior]

The fix correctly addresses issue #14: the previous or-chained expression mislabeled backend as "fts5" whenever FTS5 returned [] but the substring fallback returned hits. The new control flow matches the pattern already used in src/vouch/server.py, and not hits handles both None and empty-list returns from index_db.search.

Optional, non-blocking: consider adding a regression test that asserts backend == "substring" for a query that FTS5 tokenizes away (e.g. "auth" vs a claim containing "authentication"), per the reproducer in issue #14.

LGTM!