File search in HyperKey hands each query off to a subprocess and reads the results back over a pipe. It worked flawlessly through most of development, on a test machine with a modest Downloads folder and a handful of results per query.
Then it just... stopped
On a real machine with years of files, some queries would hang indefinitely. Not crash, not error - just sit there, as if the search had been swallowed. Nothing in the obvious places pointed to why.
The cause was almost embarrassingly simple once found: pipes have a fixed buffer, and on macOS that buffer fills at 64KB. A broad query can produce a result set larger than that in one write. If the parent process is blocked waiting for the subprocess to finish before it starts reading, and the subprocess is blocked because the pipe is full and nobody is reading it yet - both sides wait on each other forever.
The fix was smaller than the bug
Read from the pipe continuously, in a loop, on its own thread, rather than waiting for the subprocess to exit first. Once the parent is always draining the buffer, the subprocess never blocks on a full pipe, and the deadlock has nowhere to happen.
It is the kind of bug that only shows up under real conditions - which is exactly why it stayed hidden until well past the point testing was supposed to have caught it.
Why we used Spotlight instead of building our own file index
Building a custom file index sounds like the "real" way to do fast file search. It is also a second copy of your filesystem to keep correct, forever.
How I decide which app to build next
With one person and no investors, every app has to earn its place. Here is the filter an idea has to pass before it becomes a Flowstate app.
The end-of-shift habit that pays off
The value of a tip tracker is not any single number. It is the small habit of logging every shift, and what that record tells you a month later.