Recover from stalled Manifold CDN load and surface failed CAD models - #947
Draft
posthog[bot] wants to merge 1 commit into
Draft
Recover from stalled Manifold CDN load and surface failed CAD models#947posthog[bot] wants to merge 1 commit into
posthog[bot] wants to merge 1 commit into
Conversation
The 3D viewer loads the manifold-3d WASM at runtime via a dynamically injected module import from jsdelivr. If that CDN request or the WASM fetch stalls instead of failing cleanly, the `finally` block never runs, the `manifoldLoaded` event never fires, `script.onerror` doesn't catch module-import network stalls, and the UI is stuck on "Loading Manifold module..." forever with no recovery path. Add a 30s timeout around the import so a stalled load flips into the existing `manifoldLoadingError` state, and add a Retry button so the load can be re-attempted. Also guard the async callbacks against setting state after unmount. Separately, when all CAD model URL fallbacks are exhausted in AnyCadComponent, throw so the failure surfaces via the enclosing ThreeErrorBoundary -> Error3d instead of silently returning null (which made components vanish from the 3D view with no error shown). Generated-By: PostHog Code Task-Id: 03e743cb-7961-4a33-83c5-012817b3ee41
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
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.
Summary
The 3D viewer loads the
manifold-3dWASM at runtime via a dynamically injected<script type="module">that doesawait import(...)from jsdelivr. If that CDN request or the WASM fetch stalls instead of failing cleanly, the script'sfinallynever runs, themanifoldLoadedevent never fires, andscript.onerrordoesn't catch module-import network stalls — so the UI hangs on "Loading Manifold module..." forever with no recovery path.manifoldLoadingErrorstate instead of hanging indefinitely.AnyCadComponent, when all CAD model URL fallbacks are exhausted, throw so the failure surfaces via the enclosingThreeErrorBoundary→Error3dinstead of silentlyreturn null— which made components vanish from the 3D view with no error shown.Why
Users hit a permanent, unrecoverable "Loading Manifold module..." hang on the editor's primary 3D-viewing flow because the Manifold WASM is loaded from a third-party CDN with no timeout or recovery. A related gap made CAD models with exhausted fallbacks disappear silently rather than showing an error.
Follow-up worth considering (not in this PR): self-hosting/bundling the WASM to drop the hard jsdelivr dependency entirely.
Created with PostHog Code from an inbox report.