Check for other issues
Issue description
When searching with a non-empty query, structured filters are not consistently applied before FTS pagination.
FileSearchInput exposes filters such as file_types, date_range, size_range, locations, content_types, and tags. However, the persistent FTS search path applies LIMIT/OFFSET before these filters are evaluated.
As a result, search results can contain entries that do not satisfy the requested filters. Tag filters can also incorrectly return an empty page when matching tagged entries occur after the first paginated FTS results.
For example, with report.pdf and report.txt indexed, searching for:
query = "report"
file_types = ["pdf"]
can still return report.txt through the FTS path.
The total_count value also uses Name.contains(query) OR Extension.contains(query), which does not use the same matching semantics as FTS5.
Steps to reproduce
- Index a location containing files such as report.pdf and report.txt.
- Run a persistent search with query="report".
- Set file_types=["pdf"].
- Use a paginated request, for example limit=1 and offset=0.
- Observe that non-PDF entries may be returned, or the expected PDF result may be missing from the page.
The same behavior can be reproduced with date_range, size_range, content_types, locations, and tags.
Platform and versions
- OS: macOS
- Spacedrive: main branch / current development build
Development tool versions (optional)
pnpm --version:
cargo --version:
rustc --version:
Stack trace
Not applicable. This is an incorrect search result/pagination behavior.
Additional context
The existing passes_additional_filters() function already implements several of these checks, but it was not called from the non-empty FTS search path.
The fix should apply all relevant predicates before LIMIT/OFFSET and should make total_count use the same matching and filtering semantics as the returned result set.
Code of Conduct
Check for other issues
Issue description
When searching with a non-empty query, structured filters are not consistently applied before FTS pagination.
FileSearchInput exposes filters such as file_types, date_range, size_range, locations, content_types, and tags. However, the persistent FTS search path applies LIMIT/OFFSET before these filters are evaluated.
As a result, search results can contain entries that do not satisfy the requested filters. Tag filters can also incorrectly return an empty page when matching tagged entries occur after the first paginated FTS results.
For example, with report.pdf and report.txt indexed, searching for:
query = "report"
file_types = ["pdf"]
can still return report.txt through the FTS path.
The total_count value also uses Name.contains(query) OR Extension.contains(query), which does not use the same matching semantics as FTS5.
Steps to reproduce
The same behavior can be reproduced with date_range, size_range, content_types, locations, and tags.
Platform and versions
Development tool versions (optional)
Stack trace
Additional context
The existing passes_additional_filters() function already implements several of these checks, but it was not called from the non-empty FTS search path.
The fix should apply all relevant predicates before LIMIT/OFFSET and should make total_count use the same matching and filtering semantics as the returned result set.
Code of Conduct