Repository navigation
Need to explore what browser/operating system/bandwidth combinations the Explore works and does not work in #313
Description
We are observing some performance differences for the Explorer that might be due to differences in browser/operating system/bandwidth combinations. For instance, I'm using Firefox on a macbook, and the Explorer doesn't seem able to load some searches that are able to load on other people's systems. here's a screen shot:
When I try to combine two material facets, the explorer chokes and just displays "--" next to the facet counts. But Eric and Raymond were both able to load this search and get correct counts.
Could you explore whether there are browser/operating system combinations that can't run the explorer efficiently? And if there's a recomended minimum amount of bandwidth/ internet connectivity needed to run the explorer? And recommend what browser the explorer works best in? users should be able to click multiple facets on and off without the explorer crashing. They should be able to spin the globe around without it breaking.
Activity
rdhyee commentedon Jun 26, 2026
Investigation: the "--" is the honesty-dash; root cause is a boot-time loading race
Thanks @akthom — we traced this. The "--" you see isn't a crash; it's a deliberate "honesty" signal added in the recent facet-count work (#304/#305/#308): when the Explorer can't yet compute correct cross-filtered counts, it shows a dash instead of a wrong number. So your dash means the count-index wasn't ready (or failed to load) at the moment you applied the 2nd material facet.
Most likely root cause — a boot race (slow connection / Firefox)
Before multi-filter counts work, the page must download and scan ~20 MB of count data at boot (
sample_facet_masks9.7 MB + the newsample_facet_index9.7 MB, the latter via a full-table scan coverage check). On a modest or throttled connection — or a backgrounded Firefox tab, where network/timers are throttled — that takes 20–80+ seconds. If you select the 2nd facet inside that window, the count path returns "not ready" → the dash.Reproduce it (no Firefox needed)
DevTools → Network → throttle Slow 3G → hard-refresh → immediately apply 2 material facets at world zoom → "--" appears. Console:
"sample_facet_index preflight failed"= permanent dash; silence = timing race that auto-recovers after the load finishes.Prioritized fixes (full analysis attached internally)
We're evaluating P0–P6 now and will start with at least P0 (and the rest pending review). Minimum-bandwidth / best-browser guidance will come out of the live testing in your three browser/OS/bandwidth questions.
— 🤖 rbotyee+CC; static analysis + curl/duckdb probes against production data; RY reviewed
fix(explorer): three-state facet index status to fix permanent dash o…
Merge pull request #316 from rdhyee/fix/313-facet-status-p0
#313 P1: add sample_facet_index_meta build (trusted manifest, derived…
#313 P1: validate sample_facet_index_meta independently against the r…
docs(#313 P1): document sample_facet_index_meta pairing contract
#313 P1+P3: facetIndexReady reads the tiny meta manifest; decouple ma…
#313 P6: targeted Firefox spec for the facetIndexReady pending/failed…
#313 P6: fix flaky pending->failed transition in the UI-contract spec
Merge pull request #317 from rdhyee/fix/313-facet-index-manifest-p1-p3
rdhyee commentedon Jul 10, 2026
Browser + bandwidth guidance (the original ask), now that the fix is verified
@akthom — closing the loop on what this issue originally asked for. Short version: the "--" dash bug as you reported it is fixed and verified live, and here's what to expect / recommend going forward.
What changed
Your repro (two Material facets at world zoom on Firefox → "--" instead of counts) was a boot-time loading race: the readiness check used to scan ~20 MB of index data before multi-filter counts would activate — on a slow connection or backgrounded tab that took 20–80+ s, and selecting a second facet inside that window produced the dash. PR #317 (merged 2026-07-01) replaced that scan with a ~1 KB trusted manifest and moved the heavy mask load off the critical path. Verified live on isamples.org by reproducing your exact scenario: two Material facets at world zoom now return real counts (e.g. "Anthropogenic environment (157,333)"), not dashes.
Recommended minimum bandwidth
The boot-critical data is now ~0.5–0.6 MB total (measured live: 505 KB globe tiles + 59 KB vocab labels + ~3 KB manifests). Broadband or LTE: sub-second. Even slow hotel-wifi-grade connections should resolve in single-digit seconds. The DuckDB-WASM engine (~1 MB) is a one-time download your browser caches after first visit.
Browser recommendation
No browser is currently broken — the dash bug reproduced on Firefox but the root cause was connection-speed-dependent, not Firefox-specific, and the fix applies to all browsers. That said, Chrome/Chromium is the most-tested path (our CI smoke gate runs Chromium; Firefox has one targeted regression spec, not full coverage). If something looks Firefox-specific, it's the least-covered browser here — flagging which browser you're on in reports helps a lot.
What to expect (normal vs. bug)
Brief loading states are normal and intentional — the table dims with a spinner, and facet counts may briefly hold their previous value or show "Loading…". A permanent dash that never recovers, or a hard freeze, is not expected post-#317 and deserves a fresh report with browser + connection details.
Honest caveat (why this issue can stay open)
DuckDB-WASM's range-request fallback (#190) is still open and not Firefox-specific — parquet fetches can fall back to full HTTP reads. Post-#317 the affected files are mostly KB-to-low-MB so it's far cheaper, but "why does the network tab show full reads" remains a real, separate question.
(Your four new issues from yesterday — #323–#326 — are being worked now, with the #326 search bug first.)
— rbotyee 🤖 (Claude, Raymond's assistant — posted with Raymond's sign-off 2026-07-10)
CI: cheap HTTP contract test for the data origin (would have caught i…
#345: narrow HEAD+Range shim so DuckDB-WASM uses range requests again
perf: measure the Explorer across bandwidth/browsers; root-cause a 74…
Merge pull request #346 from rdhyee/perf/313-bandwidth-findings