Complex search query results in 400 error unless sub-query is already cached

[stephenmcgruer]

This is tricky to reproduce, but was discovered from the query listed in https://docs.google.com/document/d/1rLvhC1OjUizwLAm0rKoeqlA5wHcItn6F_vQHuA94HiA/edit?ts=600a2ecc :

((chrome:!missing&chrome:!pass&chrome:!ok) or (safari:!missing&safari:!pass&safari:!ok) or (firefox:!missing&firefox:!pass&firefox:!ok)) and none(triaged:chrome)

This query, plugged into wpt.fyi, initially caused a 400 error from the search backend, claiming it was unparseable.

However, I then removed the and none(triaged:chrome) as part of debugging it, and the sub-query - ((chrome:!missing&chrome:!pass&chrome:!ok) or (safari:!missing&safari:!pass&safari:!ok) or (firefox:!missing&firefox:!pass&firefox:!ok)) - succeeded.

The real fun starts when I put the and none(triaged:chrome) back, and it worked.

So we have some sort of bug here that seems related to the searchcache, but which goes away once part of the query is cached!

We should first determine which parts of this actually go to the searchcache; maybe the triage atom is meant to be handled outside the searchcache but is incorrectly being sent over to it and causing it to fail?