Summary
After committing a free-text (or concept) search, the facet-legend counts — most visibly the always-on source counts — keep showing viewport-only numbers that ignore the active search. They are not a brief transient: observed stuck for ≥7 s (with explorer-busy already cleared). They correct to the proper search-filtered values only after the user interacts with a facet section, which forces a fresh recompute.
This is the visible residue of the "bucchero pulls SESAR" report (2026-05-29 tech call). The #250 fix corrected the results/table ("N of N matches in this map view" is right; result rows are OpenContext-only). The legend counts were not fully covered.
Reproduce (staging or isamples.org)
…/explorer.html#v=1&lat=42.5&lng=12.0&alt=400000- Search
bucchero (world scope, the default — Enter in the search box).
- Watch the source legend: it shows e.g.
SESAR (2,573) and stays there.
- Ground truth: bucchero = 2,693 samples, 100% OpenContext, 0 SESAR. So the legend should read
SESAR (0), OpenContext (~2,670 in view).
- Now expand any facet section (Material / Sampled Feature / Specimen Type) → a recompute fires → source corrects to
SESAR (0) and the expanded dimension reads the bucchero-filtered breakdown (e.g. object_type artifact (~2,289), othersolidobject (0); material anthropogenicmetal (~2,660), earthmaterial (0)).
Root cause (important — the SQL is already correct)
updateCrossFilteredCounts() (explorer.qmd ~L2887) does apply the search_pids semi-join via searchFilterSQL('f.pid') in its slow path (~L2994), and correctly gates off the cube/baseline fast-paths when searchIsActive() (L2930, L2945). source is one of its dims (L2855). So when this function runs with the search active, the counts are right.
The bug is sequencing: a committed world-scope search auto-flies the camera to the first result, and that flight's camera.changed / moveEnd cascade appears to leave the legend showing a pre-search / in-flight viewport recompute rather than a final search-aware one. The committed search does not reliably trigger a last, un-superseded refreshFacetCounts() after the flyto settles.
Suggested fix direction
Ensure a committed search fires a final, un-superseded search-aware count recompute after the auto-flyto settles (and/or have the flyto-triggered recompute read the now-active search state). Verify across world + area scope and the described-by= concept producer (#248), which shares the same path.
Decisive test not yet run
An area-scope search (no auto-flyto): if the legend settles to (0) correctly with no camera flight, that confirms the flyto as the culprit.
Context: A1 #234 step 4 / #251; cross-source results fix #250; concept filter #248 (#252).
Summary
After committing a free-text (or concept) search, the facet-legend counts — most visibly the always-on source counts — keep showing viewport-only numbers that ignore the active search. They are not a brief transient: observed stuck for ≥7 s (with
explorer-busyalready cleared). They correct to the proper search-filtered values only after the user interacts with a facet section, which forces a fresh recompute.This is the visible residue of the "bucchero pulls SESAR" report (2026-05-29 tech call). The #250 fix corrected the results/table ("N of N matches in this map view" is right; result rows are OpenContext-only). The legend counts were not fully covered.
Reproduce (staging or isamples.org)
…/explorer.html#v=1&lat=42.5&lng=12.0&alt=400000bucchero(world scope, the default — Enter in the search box).SESAR (2,573)and stays there.SESAR (0),OpenContext (~2,670 in view).SESAR (0)and the expanded dimension reads the bucchero-filtered breakdown (e.g. object_typeartifact (~2,289),othersolidobject (0); materialanthropogenicmetal (~2,660),earthmaterial (0)).Root cause (important — the SQL is already correct)
updateCrossFilteredCounts()(explorer.qmd ~L2887) does apply thesearch_pidssemi-join viasearchFilterSQL('f.pid')in its slow path (~L2994), and correctly gates off the cube/baseline fast-paths whensearchIsActive()(L2930, L2945).sourceis one of itsdims(L2855). So when this function runs with the search active, the counts are right.The bug is sequencing: a committed world-scope search auto-flies the camera to the first result, and that flight's
camera.changed/moveEndcascade appears to leave the legend showing a pre-search / in-flight viewport recompute rather than a final search-aware one. The committed search does not reliably trigger a last, un-supersededrefreshFacetCounts()after the flyto settles.Suggested fix direction
Ensure a committed search fires a final, un-superseded search-aware count recompute after the auto-flyto settles (and/or have the flyto-triggered recompute read the now-active search state). Verify across world + area scope and the
described-by=concept producer (#248), which shares the same path.Decisive test not yet run
An area-scope search (no auto-flyto): if the legend settles to
(0)correctly with no camera flight, that confirms the flyto as the culprit.Context: A1 #234 step 4 / #251; cross-source results fix #250; concept filter #248 (#252).