fix(firestore): keep non-filter constraints out of Query.and composite

[detail-app]

Detail bug report: View on Detail

Closes #94

Bug

Query.and(...) mixes filter (where) and non-filter (orderBy, limit, cursors) constraints in a single call — a pattern shown across its JSDoc, the README, and AGENTS.md. Its flatten-vs-wrap heuristic has two branches: with no nested And/Or it returns the constraints flat (works); when any child is an And/Or it wraps all children — including OrderBy/Limit/LimitToLast and the cursor constraints — into one And node. The Client and Admin query builders route every child of an And/Or through filter-only conversion and throw Cannot use <Tag> inside AND/OR composite filters on the non-filter ones. The crash only surfaces when a nested or(...) and a non-filter constraint are passed to the same Query.and(...) call; the transition from "works" to "crashes" is invisible to the caller.

Fix

In packages/effect-firebase/src/lib/firestore/query/query.ts, when Query.and decides to wrap, it now partitions the children: only filter constraints (Where/And/Or) go into the And composite; non-filter constraints are returned as top-level siblings after the composite, preserving their relative order. The emitted shape [and(filters...), orderBy, limit] is exactly what the Firestore client SDK's validateQueryConstraintArray accepts (compositeFilterCount=1, fieldFilterCount=0), and what both builders already handle on their non-composite path. Query.or is untouched (it is filter-only by contract). Introduced in 8e11e17.

Testing

• New regression specs for the Query.and/Query.or combinators (core), the client builder, the admin builder, and the mock backend. With the fix reverted, 15 of those tests fail (builder throws, mock returns wrong/unsorted/unlimited results, structural asserts break); with the fix, all 52 pass.
• Mock tests assert the wrapped form now filters, sorts, and limits identically to the equivalent pipeable addOrderBy/addLimit form (['And','OrderBy','Limit']).
• End-to-end against the Firestore emulator: inserted 5 documents and ran the fix's emitted shape through the real client SDK — returned the expected filtered (published AND news-or-tech), sorted (category desc), limited rows.
• The client SDK's synchronous validateQueryConstraintArray confirms the spread form [where, or, orderBy, limit] is still rejected (the SDK's own restriction, unchanged) while the fix's [and(where, or), orderBy, limit] shape is accepted.
• Whole-repo build, test, and lint all pass (build for 8 projects, test for 6 projects, lint for 8 projects with 0 errors); prettier clean on the changed files.

---

Automatic Fixes PRs can be configured here.

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge, with the previous test-import findings fully addressed and no new actionable issues identified.

Summary

This PR fixes Query.and(...) so nested composite filters no longer absorb ordering, limits, or cursor constraints.

• Partitions constraints into filter and non-filter groups when a nested And or Or requires wrapping.
• Emits non-filter constraints as top-level siblings while preserving their relative order.
• Adds coverage across core query composition, client and admin builders, and the mock backend.
• Updates the remaining test-helper imports to use the repository-required @effect/vitest package.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Query.and(...constraints)"] --> B{"Contains nested And or Or?"}
    B -->|No| C["Return constraints unchanged"]
    B -->|Yes| D["Partition constraints"]
    D --> E["Filters: Where / And / Or"]
    D --> F["Non-filters: ordering / limits / cursors"]
    E --> G["Wrap filters in And"]
    G --> H["Return And plus non-filter siblings"]
    F --> H

Loading

_{Reviews (3) · Last reviewed commit: "test(firestore): import query-combinator..."}