Ask for a GPU adapter before downloading 314 MB, not after - #8
Merged
Conversation
Found by screenshotting production and actually looking at it. A visitor
without usable WebGPU saw a raw JavaScript error — "Cannot read properties of
undefined (reading 'requestAdapter')" — with the flybody bundle 36% downloaded
behind it.
The guard was `!("gpu" in navigator)`, an existence check. That catches Firefox
and older Safari, where the property is absent. It does not catch the case
where the property exists and the adapter does not: a blocklisted GPU, or a VM
without passthrough. Chrome exposes navigator.gpu there and hands back null
from requestAdapter, so that visitor sailed past the bail, downloaded the
connectome and the body, and crashed on the first adapter call.
Now it asks for the adapter up front and treats a null or throwing result the
same as a missing property. Verified against both shapes with the property
deleted (Firefox) and with requestAdapter stubbed to return null (blocklisted
GPU): zero .bin requests in each, the friendly message, and a working relative
link to the landing page.
The message also stopped claiming the browser is at fault, since in the
blocklist case it usually is not.
e2e 34/34 — one KC-sparsity failure during the run re-ran clean on an idle
machine, and the other two KC assertions passed in the same loaded run, which
is what a genuine dynamics shift would not do.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by screenshotting production and actually looking at it. A visitor without usable WebGPU saw a raw JavaScript error —
Cannot read properties of undefined (reading 'requestAdapter')— with the flybody bundle 36% downloaded behind it.The gap
The guard was
!("gpu" in navigator)— an existence check. That catches Firefox and older Safari, where the property is absent. It does not catch the case where the property exists and the adapter does not: a blocklisted GPU, or a VM without passthrough. Chrome exposesnavigator.gputhere and returnsnullfromrequestAdapter(), so that visitor sailed past the bail, downloaded the connectome and the body, and crashed on the first adapter call.The fix
Ask for the adapter up front; treat null-or-throws the same as a missing property. Verified against both real-world shapes:
.binrequestsindex.html✓requestAdapter → null(blocklist)index.html✓The message also stopped claiming the browser is at fault, since in the blocklist case it usually isn't.
Verification
tscclean · e2e 34/34. One KC-sparsity failure during the run re-ran clean on an idle machine; the other two KC assertions passed in that same loaded run, which is what a genuine dynamics shift would not do.Context:
vnc.binwas also rebuilt and re-uploaded (not in this diff — the binaries are gitignored)The shipped blob had not been built by the committed
build_vnc.py. Rebuilt from MANC source and pushed to R2, with the manifest bumped0397588831cc → 32f66b946a16:sign≠0withnt_conf < 0.5(impossible per the script)nt_conf(impossible per the script)Neuron and edge counts are identical (23,188 / 5,243,574). Validated locally at 34/34 before upload; R2, Pages and the HF Space all serve the new manifest.
🤖 Generated with Claude Code