fix(devframe): dedup wire-service install across contexts sharing an RPC host - #338
Merged
Conversation
…RPC host A single wire service declared on a definition could register its RPC twice and trip DF0021 when the definition is mounted into two contexts backed by one RPC host (e.g. a kit mounting it alongside another context, so both iterate def.services). The install-dedup guard was per services-host instance, so the second context re-ran the service factory and re-registered its RPC. Key the dedup registry by the shared RPC host so the first install wins across sibling contexts; a sibling hit reuses the cached API without re-running setup, while a genuine same-host re-install still warns DF0066.
◈ PR Lens
Architecture 
1 component touched across 3 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.
Closes #335.
Problem
Declaring a wire service once on a definition (e.g.
services: [{ package: '@devframes/service-open' }]) could emit aDF0021 RPC function "…" is already registeredwarning at startup. When the definition is mounted such that itsservicesare installed by two devframe contexts that share a single RPC host (the shape the reporter traced in a kit-mounted setup), the service factorysetupruns twice, so the second context re-registers the service's RPC and trips DF0021. The service still worked (first registration won), but the warning was noisy and misleading.Cause
The services-host install-dedup guard (
installed) was per host instance. Two contexts have two services hosts, so neither sees the other's install — and when they share one RPC host, the second install collides on the RPC registration.Fix
Key the install-dedup registry by the shared RPC host object (a
WeakMap<rpcHost, Map<pkg, api>>) instead of per-instance. The first install of a package now wins across every context on that RPC host. A sibling-context hit reuses the cached API and exposes it locally without re-running the factory (so no re-registration, no DF0021); a genuine same-host re-install still warns DF0066 as before. A context-less host (in-processprovide/getonly) falls back to a per-instance map.Added a regression test covering two contexts that share one RPC host installing the same service: the factory runs once, the RPC is registered once and stays callable, both contexts expose the API, and no DF0021 is emitted.
This PR was created with the help of an agent.