Text search (still) doesn't update facet counts correctly

[ekansa]

I tried a text search for the suggested "pottery Cyprus": https://isamples.org/explorer.html?search=pottery+Cyprus#v=1&lat=35.3300&lng=33.0659&alt=200000&mode=point

It says that it found a total of 1305 results, but the counts for various facet options typically greatly exceed the total number of search results. The facet counts need to be recalculated based on the full-text search filter.

[rdhyee]

🤖 rbotyee (Claude, operated by @rdhyee) — Raymond's intent: get a cheap, honest fix in before the grant closes, and tell Eric straight what we found. What I did: reproduced #340, tracked down the cause, shipped a fix in #341 (now live on isamples.org), and wrote it up here.

Thanks Eric — confirmed, and it's a bit worse than it looked. Those facet numbers weren't just too high, they were the whole-database totals, completely ignoring your search. Every one of the 1,305 matches is OpenContext, but SESAR was still sitting there claiming 4,389,231.

What's actually going wrong

It's not that we forgot to apply the search to the counts. That part exists. The problem is that the recalculation starts and then never finishes — and while it's running, the numbers on screen just go slightly greyed out. The text itself never changes. So the old, wrong numbers stay up looking perfectly normal, indefinitely.

That's why this was easy to miss: there's no error, no spinner, no blank. It just quietly keeps showing you the last answer it had. I watched it sit there unfinished 15+ seconds after the search was done, and moving the map around didn't jog it loose either.

What we've done about it (#341, deployed)

Making the counts actually respect a search is the unfinished half of the #305 plan, and it isn't something we can responsibly finish and test in the time left.

So instead of leaving wrong numbers on screen, a search now shows (—) for every count — an honest "we don't know" rather than a confident wrong answer. That's your own request from #304, taken literally: "make sure the user interface does NOT show inaccurate numbers."

Clear the search and the real numbers come straight back. Filtering by facets on its own is untouched and still works normally.

Verified on the live site just now: with ?search=pottery+Cyprus all 60 count elements show the dash and none are stuck mid-recalculation; with a facet filter and no search, real cross-filtered counts still appear (SESAR 0, OpenContext 261,086 for Artifact).

I'm deliberately leaving this issue open

A dash is honest, but it isn't what you asked for — you wanted counts that update. If that matters more than the honest placeholder, it's still on the table as future work, and I've written down what the next person needs to know in PLAN_305_facet_counts.md, including the part we couldn't figure out: where exactly the calculation gets stuck.

Two other things worth flagging

We swept for the same class of problem elsewhere, since "a number that quietly stops updating" seemed unlikely to be a one-off. It wasn't — we found several more spots where a stalled or failed lookup can leave an old number on screen with nothing indicating it's stale. Two are worth knowing about as a user: if a lookup fails while you have a dense area selected in point mode, the panel can report the 5,000-sample display cap as though it were the true total; and the search results list keeps its original count if you toggle facets while a search is active. None of these are fixed — they're documented for whoever picks this up, with the reasoning and line references.

Our own documentation had drifted. EXPLORER_STATE.md still said search and map position don't affect facet counts, which stopped being true months ago. Fixed that too.

Separately — thanks for the Poggio Civitate similarity-weights visualization. I couldn't get it to finish loading on my end, but that may well be something my side; I didn't want to call it broken without a proper second look.