fix(search): drop subquery wrapper that leaked LIMIT into COUNT

[abdout]

Hotfix. Verified live regression introduced by #26.

The bug

After #26 deployed, every autocomplete result returns listingCount = limit instead of the true count:

$ curl -s 'https://mk.databayt.org/api/search/locations?q=port&limit=1'
{"data":[{"city":"Port Sudan", ..., "listingCount": 1}]}    ❌

$ curl -s 'https://mk.databayt.org/api/search/locations?q=port&limit=10'
{"data":[{"city":"Port Sudan", ..., "listingCount": 10}]}   ❌

$ curl -s 'https://mk.databayt.org/api/search/locations?q=port&limit=20'
{"data":[{"city":"Port Sudan", ..., "listingCount": 20}]}   ❌

$ curl -s 'https://mk.databayt.org/api/search/locations?q='   # popular path
{"data":[{"city":"Port Sudan", ..., "listingCount": 100}]}  ✅

The popular-locations path (single SELECT, no subquery wrapper) returns 100 correctly against the same data. So the data and the JOIN are fine — the bug is in the trigram subquery shape.

Root cause

#26 wrapped the aggregation in a subquery to keep similarity(l.city, $q) out of the GROUP BY (so it could be ranked in the outer ORDER BY):

-- broken
SELECT city, state, country, n, sim FROM (
  SELECT l.city, l.state, l.country,
         COUNT(li.id)::bigint AS n,
         GREATEST(similarity(...), ...) AS sim
  FROM ...
  GROUP BY l.city, l.state, l.country
) sub
ORDER BY n DESC, sim DESC
LIMIT $limit;

Under that shape the planner pushes the outer LIMIT into the inner GROUP BY's COUNT — a Postgres planner pathology that surfaces with GIN-indexed predicates plus an outer LIMIT over aggregates. Result: COUNT(*) ≡ LIMIT.

Fix

Drop the subquery. Aggregate similarity with MAX(GREATEST(...)) in the same SELECT as COUNT:

-- correct
SELECT l.city, l.state, l.country,
       COUNT(li.id)::bigint AS n,
       MAX(GREATEST(
         similarity(l.city,    $1),
         similarity(l.state,   $1),
         similarity(l.country, $1)
       )) AS sim
FROM "Location" l
JOIN "Listing" li ON li."locationId" = l.id
WHERE ...
GROUP BY l.city, l.state, l.country
ORDER BY n DESC, sim DESC
LIMIT $5;

similarity(grouped_col, const) is functionally constant per group, so MAX is idempotent — same ranking semantics, no subquery, no planner bug.

Validation

• pnpm typecheck → exit 0
• pnpm vitest run tests/actions/search-actions.test.ts → 19 / 19 pass
• After Vercel deploys this PR, expect ?q=port&limit=1 → listingCount=100

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
mkan	Ready	Preview, Comment	May 10, 2026 6:17am