fix(knowledge): treat a reach of nothing as a bounded set of nothing

[waleedlatif1]

Summary

• A member who reads no document in the bases (for example one who has not connected a source of their own yet) resolved as an unbounded reach. The vector leg then scanned the sliced sources for readable rows it could not find until its 3 s deadline, and the keyword leg ranked every match of the term to the same end, so a search that could only return nothing spent every budget it had. Measured on production with the replay harness: 8.3 s per search, both legs timed out, zero results
• A counted reach of zero is now a bounded empty set, remembered for the same window as any reach, and both legs answer immediately. An index the planner has no row estimate for keeps its old answer, since a bound of zero looks at nothing and cannot prove emptiness
• The count already runs under the probe's share of the deadline (fix(knowledge): give the reach count the probe's share of the deadline, not the leg's #8111); this change only interprets its result

Type of Change

• Bug fix

Testing

• New tests: a reach of nothing resolves as a bounded empty set on both the resolved-scope and the probe path, is remembered so the next search neither counts nor probes; an unanalyzed index is not read as a reach of nothing. The first fails with the emptiness check removed
• vitest over lib/knowledge and app/api/knowledge (191 files, 3307 tests), bun run lint, bun run check:audits and native tsc --noEmit pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Sep 21, 2026 7:06pm UTC

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; both previously reported correctness issues are fixed and no new actionable failures remain.

Summary

This PR makes a permission-scoped reach count of zero resolve to an explicitly bounded empty document set, allowing vector and keyword retrieval to return immediately instead of scanning until their deadlines.

• Handles zero reach consistently in both direct reach resolution and the saturated-probe path.
• Avoids caching emptiness so newly indexed or newly accessible documents become visible on the next search.
• Preserves the unbounded fallback when the planner's row estimate is zero and the count therefore examined nothing.
• Adds focused regression tests for direct, saturated-probe, repeated-search, and unanalyzed-index behavior.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Resolve permitted documents] --> B{Cached breadth?}
    B -- Yes --> C[Use unbounded strategy]
    B -- No --> D[Probe or count reachable documents]
    D --> E{Count examined rows?}
    E -- No: bound is zero --> C
    E -- Yes --> F{Reach count is zero?}
    F -- Yes --> G[Return bounded empty set]
    F -- No --> H[Return unbounded strategy]
    G --> I[Vector and keyword legs return immediately]
    H --> J[Retrieval runs with full access predicate]
    C --> J

Loading

_{Reviews (2) · Last reviewed commit: "fix(knowledge): count emptiness on every..."}

[cubic-dev-ai]

All reported issues were addressed across 2 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[waleedlatif1]

@greptile

[waleedlatif1]

@cubic-dev-ai review this PR

[cubic-dev-ai]

@cubic-dev-ai review this PR

@waleedlatif1 I have started the AI code review. It will take a few minutes to complete.

[cubic-dev-ai]

No issues found across 2 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}