Search logic uses AND across email/name; should be OR. Also needs empty‑query guard.

Current block applies both email.search and name.search simultaneously (AND), causing near-zero matches and potential FTS errors when sanitized is empty.

Fix:

-    const commonWhere: Prisma.PartnerWhereInput = {
-      ...(email
-        ? { email }
-        : search
-          ? search.includes("@")
-            ? { email: search }
-            : {
-                email: { search: sanitizeFullTextSearch(search) },
-                name: { search: sanitizeFullTextSearch(search) },
-              }
-          : {}),
+    const sanitized =
+      search && !search.includes("@") ? sanitizeFullTextSearch(search) : undefined;
+
+    const searchWhere: Prisma.PartnerWhereInput =
+      email
+        ? { email }
+        : search
+        ? search.includes("@")
+          ? { email: search }
+          : sanitized
+          ? {
+              OR: [
+                { email: { search: sanitized } },
+                { name:  { search: sanitized } },
+              ],
+            }
+          : {}
+        : {};
+
+    const commonWhere: Prisma.PartnerWhereInput = {
+      ...searchWhere,
       ...(partnerIds && {
         id: { in: partnerIds },
       }),
     };

Consider making the email match case‑insensitive or partial if desired UX (e.g., contains with mode: 'insensitive'). Please confirm DB/provider supports the chosen FTS semantics.

I'll verify the review comment by examining the actual codebase.

🏁 Script executed:

#!/bin/bash
# 1. Check if the file exists and show lines around 17-27
fd "route.ts" --path "*partners/count*" --exec cat {} \;

Length of output: 215

🏁 Script executed:

#!/bin/bash
# 2. Find the sanitizeFullTextSearch function definition to understand its behavior
rg -n "sanitizeFullTextSearch" -A 5 -B 2 --type=ts --type=js

Length of output: 3320

🏁 Script executed:

#!/bin/bash
# 3. Get full context of the route.ts file to understand the complete logic
fd "route.ts" --path "*partners/count*" --exec wc -l {} \;

Length of output: 215

🏁 Script executed:

#!/bin/bash
# 4. Check Prisma schema to understand PartnerWhereInput structure
fd "schema.prisma" --exec cat {} \;

Length of output: 2710

🏁 Script executed:

#!/bin/bash
# Get full content of the partners count route file
cat "apps/web/app/(ee)/api/partners/count/route.ts"

Length of output: 3722

🏁 Script executed:

#!/bin/bash
# Find full where-clause context with more lines before/after
rg -n "commonWhere" -B 10 -A 5 "apps/web/app/(ee)/api/partners/count/route.ts"

Length of output: 2161

🏁 Script executed:

#!/bin/bash
# Check how the where clause is actually used in the query
rg -n "where.*commonWhere" -A 3 -B 3 --type=ts "apps/web/app/(ee)/api/partners/count"

Length of output: 0

Use OR across email/name and guard empty sanitized search.

Current where merges email.search and name.search as AND and doesn’t guard empty sanitized input.

Apply:

-              ...(email
-                ? { email }
-                : search
-                  ? search.includes("@")
-                    ? { email: search }
-                    : {
-                        email: { search: sanitizeFullTextSearch(search) },
-                        name: { search: sanitizeFullTextSearch(search) },
-                      }
-                  : {}),
+              ...(email
+                ? { email }
+                : search
+                ? search.includes("@")
+                  ? { email: search }
+                  : sanitizedSearch
+                  ? {
+                      OR: [
+                        { email: { search: sanitizedSearch } },
+                        { name:  { search: sanitizedSearch } },
+                      ],
+                    }
+                  : {}
+                : {}),

Add above the query (after destructuring):

const sanitizedSearch =
  search && !search.includes("@") ? sanitizeFullTextSearch(search) : undefined;

Please verify that results now include matches where either name or email satisfies the query and that whitespace‑only queries don’t throw.

---

🏁 Script executed:

```shell
#!/bin/bash
# Find and inspect the get-partners.ts file
fd 'get-partners\.ts' --type f

Length of output: 41

🏁 Script executed:

#!/bin/bash
# Inspect the file context around lines 40-70
cat apps/web/lib/api/partners/get-partners.ts | head -80 | tail -50

Length of output: 1080

🏁 Script executed:

#!/bin/bash
# Search for sanitizeFullTextSearch definition
rg -n 'sanitizeFullTextSearch' --type ts --type js -B2 -A5

Length of output: 3320

🏁 Script executed:

#!/bin/bash
# Look for count route mentioned in review
rg -n 'count.*where' apps/web/lib/api/partners/ -B3 -A3 --type ts

Length of output: 0

🏁 Script executed:

#!/bin/bash
# Get full context of the query to understand its structure
cat apps/web/lib/api/partners/get-partners.ts | head -100

Length of output: 2148

---

🏁 Script executed:

```shell
#!/bin/bash
# Inspect count route to compare with get-partners.ts
cat apps/web/app/(ee)/api/partners/count/route.ts

Length of output: 136

🏁 Script executed:

#!/bin/bash
# Search for other uses of Prisma OR pattern to confirm syntax
rg -n 'OR:\s*\[' apps/ -A3 --type ts --type js | head -40

Length of output: 2239

🏁 Script executed:

#!/bin/bash
# Verify sanitizeFullTextSearch edge cases
python3 << 'EOF'
import re

def sanitizeFullTextSearch(search):
    return re.sub(r'[*+\- ()~@%<>!=?:\s]', '', search).strip()

# Test cases
test_cases = [
    "john doe",
    "   ",
    "***---",
    "@@@",
    "[email protected]",
    "normal",
]

for test in test_cases:
    result = sanitizeFullTextSearch(test)
    print(f"'{test}' → '{result}' (empty: {not result})")
EOF

Length of output: 200

---

🏁 Script executed:

```shell
#!/bin/bash
# Find and read count route with proper escaping
find apps/web/app -path "*partners/count/route.ts" -type f -exec cat {} \;

Length of output: 7640

🏁 Script executed:

#!/bin/bash
# Confirm both files have the same search pattern issue
rg -n 'email.*search.*sanitizeFullTextSearch' apps/web/lib/api/partners/get-partners.ts apps/web/app -B1 -A1 --type ts

Length of output: 606

Sanitizer can produce empty queries and over‑sanitize (drops spaces).

• Returning "" risks FTS errors downstream.
• Removing whitespace downgrades multi‑token search.

Refine and keep tokens:

-export const sanitizeFullTextSearch = (search: string) => {
-  // remove unsupported characters for full text search
-  // '*', '+', '-', ' ', '(', ')', '~', '@','%', '<', '>', '=', '|', '!', '?', ':'
-  return search.replace(/[*+\- ()~@%<>!=?:\s]/g, "").trim();
-};
+export const sanitizeFullTextSearch = (search: string) => {
+  // Keep letters/numbers/spaces; strip punctuation; collapse whitespace.
+  const sanitized = search
+    .normalize("NFKC")
+    .replace(/[^\p{L}\p{N}\s]+/gu, " ")
+    .replace(/\s+/g, " ")
+    .trim();
+  return sanitized;
+};

Please verify behavior for inputs like "john doe", "john-doe", "***", and whitespace-only.

I'll verify this review comment by examining the codebase and understanding the Prisma FTS constraints.

🏁 Script executed:

#!/bin/bash
# Find the file and inspect current implementation
fd -t f "index.ts" packages/prisma 2>/dev/null | head -5

Length of output: 24

🏁 Script executed:

#!/bin/bash
# Check content of the file
cat packages/prisma/index.ts

Length of output: 617

🏁 Script executed:

#!/bin/bash
# Search for uses of sanitizeFullTextSearch
rg -n "sanitizeFullTextSearch" --type=ts --type=js -C2

Length of output: 2331

🏁 Script executed:

#!/bin/bash
# Test the regex patterns and function behavior
node << 'EOF'
// Current implementation
const current = (search) => {
  return search.replace(/[*+\- ()~@%<>!=?:\s]/g, "").trim();
};

// Proposed implementation
const proposed = (search) => {
  const sanitized = search
    .normalize("NFKC")
    .replace(/[^\p{L}\p{N}\s]+/gu, " ")
    .replace(/\s+/g, " ")
    .trim();
  return sanitized;
};

const testCases = ["john doe", "john-doe", "***", "   ", "", "hello  world", "@@@test"];

console.log("TEST RESULTS:");
console.log("=".repeat(60));
testCases.forEach(input => {
  const curr = current(input);
  const prop = proposed(input);
  console.log(`Input: "${input}"`);
  console.log(`  Current: "${curr}" (empty: ${curr === ""})`);
  console.log(`  Proposed: "${prop}" (empty: ${prop === ""})`);
  console.log();
});
EOF

Length of output: 658

🌐 Web query:

Prisma full text search empty string MATCH AGAINST behavior PostgreSQL

💡 Result:

Short answer

• Prisma's Postgres full-text search delegates to PostgreSQL. An empty/blank search string produces a tsquery with no lexemes (effectively an empty/non‑indexable query), so the match (@@) yields no matches — i.e., you get no rows unless you handle the empty input in your app/ORM layer. [1][2][3]

Why

• Prisma's FTS API uses the database's native text‑search machinery (so behavior comes from PostgreSQL). [1]
• PostgreSQL text‑search helpers such as plainto_tsquery/websearch_to_tsquery convert input text into a tsquery; if no lexemes survive (empty string or only stopwords), the resulting query is non‑indexable / empty and will not match documents. This is documented in PostgreSQL and reported in user Q&As. [2][3]

What to do

• Check for empty/blank search strings in your application and:
  • skip the full‑text filter (return all rows or apply other filters), or
  • treat empty as a special case (e.g., fallback to ILIKE or a different query), or
  • build a tsquery yourself (e.g., avoid calling plainto_tsquery with '') if you want different behavior.
• If you need web‑style parsing, consider websearch_to_tsquery but still guard empty input. [2][4]

References

• Prisma docs: Full‑text search (Postgres uses DB native queries). [1]
• PostgreSQL text‑search functions/operators (plainto_tsquery/websearch_to_tsquery, behavior with no surviving lexemes). [2]
• Reports / Q&A showing plainto_tsquery/tsquery empty/no matches for empty/stopword inputs. [3]
• PostgreSQL websearch_to_tsquery documentation (alternative, but still requires non‑empty input). [4]

Sources
[1] Prisma — Full‑Text Search (PostgreSQL).
[2] PostgreSQL docs — Text Search Functions and Operators / Controlling Text Search.
[3] Example discussions: StackOverflow (plainto_tsquery/no lexemes) and related threads.
[4] PostgreSQL docs — websearch_to_tsquery / plainto_tsquery.

🏁 Script executed:

#!/bin/bash
# Check if usage sites guard against empty strings after sanitization
cat apps/web/lib/api/partners/get-partners.ts | sed -n '50,70p'

Length of output: 556

🏁 Script executed:

#!/bin/bash
# Check the second usage site
cat apps/web/app/(ee)/api/partners/count/route.ts | sed -n '15,35p'

Length of output: 154

🏁 Script executed:

#!/bin/bash
# Fix path escaping for second usage site
cat "apps/web/app/(ee)/api/partners/count/route.ts" | sed -n '15,35p'

Length of output: 576

🏁 Script executed:

#!/bin/bash
# Get broader context around first usage to see full conditional logic
cat apps/web/lib/api/partners/get-partners.ts | sed -n '40,75p'

Length of output: 839