fix: only invoke onRuntimeError with null after a previously reported error#96
Closed
git-chad wants to merge 1 commit into
Closed
fix: only invoke onRuntimeError with null after a previously reported error#96git-chad wants to merge 1 commit into
git-chad wants to merge 1 commit into
Conversation
… error ShaderLabComposition called the consumer onRuntimeError callback with null after every successful renderer initialization (and after every successful shader recompile via the internal error channel), because null was used as a success/cleared signal on the same path as real errors. Consumers following the README example logged "null" on every clean init, and apps mirroring the message into UI state showed a permanent false error. The composition now tracks the last message actually delivered to the consumer in a ref that survives config-change re-inits: - null on a clean init is a no-op toward the consumer (internal error overlay state is still cleared) - after a real error was delivered, resolving it calls the consumer with null exactly once so error UIs can recover - consecutive identical errors and repeated clears are deduplicated Also documents the callback semantics in the onRuntimeError JSDoc and the README error-handling example, and adds a patch changeset. Fixes #81 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This was referenced Jul 7, 2026
Closed
Collaborator
Author
|
Consolidated into #104. |
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.
Closes #81.
Problem
<ShaderLabComposition>calledonRuntimeError(null)after every successful renderer init and config change (thenullwas an internal "clear error state" signal leaking through the consumer callback). The README example doesn't null-check, so anyone copying it loggednullerrors — or pinned a permanent false error in their UI.Fix
handleRuntimeErrorstill updates the internal overlay state unconditionally, but only invokes the consumer callback when the message differs from the last delivered one (tracked in a component-level ref that survives config-change effect re-runs). ThebrowserSupportsWebGPU()failure branch now routes through the same funnel.Consumer-visible behavior:
nullnullagainnullexactly onceAlso documents the semantics on the prop's JSDoc and updates both READMEs' example to null-check (with a paragraph explaining the
null-on-recovery contract).Patch changeset included.
Verification
Package typecheck,
bun run build:runtime,bun run typecheck:tsc,bun run lint,bun test, andbunx changeset status --since=origin/mainall pass.Stacked on #92 (lint cleanup). Merge #92 first; GitHub retargets this to
main.🤖 Generated with Claude Code