fix: resolve in-page channel functions across chained registries - #378
Merged
Conversation
The DF0077 "not registered" fallback and the channelMethod wrapping introduced in #371 broke every user call and all shared-state traffic: the per-name fallback made a registry return a throwing handler for any unknown function name, so chaining `stateRegistry.resolve ?? registry.resolve` short-circuited before the real registry was consulted, and the state layer's already-namespaced handlers got double-prefixed by channelMethod. Move the fallback into a resolveLocalHandler seam that runs after every registry, and register the shared-state handlers verbatim.
◈ PR Lens
Architecture 
1 component touched across 2 lanes. Data flow 
Drill down
|
|
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
2 participants
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.
Intent
CI on
mainis red: thein-page-channelunit suite fails 17 tests and the a11y hub-static e2e specs fail, because #371 ("separate in-page channel events from functions") introduced two regressions in the endpoint's local function table.The DF0077 "not registered" fallback was returned per-registry: any unknown
function:-prefixed name made a registry hand back a throwing handler. Both endpoints resolve withstateRegistry.resolve(name) ?? registry.resolve(name), so the first registry's throwing handler short-circuited the??and the real user registry was never consulted — every usercallthrew "function … is not registered".channelMethodwrapping was applied at registration time to the shared-state handlers too, but those handlers are keyed by their own fully-qualified wire methods (devframe:in-page:page-state:*and the panel-state events). Double-prefixing them meant no state request or notification ever resolved, hanging every shared-state test and the a11y panel's scan.Change
resolveLocalHandlerseam that runs after every registry, so chaining never masks a real handler.registerInternal, bypassingchannelMethod.Full local run green:
lint,knip,test(1515 pass),typecheck,build, and the previously-failinga11y-messages-hub-statice2e (4 pass).This PR was created with the help of an agent.