Generalize ContainerRuntime.loadRuntime to allow custom Registry#27685
Draft
CraigMacomber wants to merge 1 commit into
Draft
Generalize ContainerRuntime.loadRuntime to allow custom Registry#27685CraigMacomber wants to merge 1 commit into
CraigMacomber wants to merge 1 commit into
Conversation
Extends the loadRuntime API to accept an optional entryPointFactory that enables the new ServiceClient pattern to set an arbitrary root data store as the container entry point rather than always using the single hard-coded root store. Also updates all call sites that pass a runtime creation callback (testContainerRuntimeFactory, replayFluidFactories, mixinAttributor) to match the revised signature, and adjusts the unit and compat tests to reflect the new parameter. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
Hi! Thank you for opening this PR. Want me to review it? Based on the diff (159 lines, 6 files), I've queued these reviewers:
How this works
|
CraigMacomber
commented
Jul 14, 2026
| * @returns An object containing the runtime. | ||
| * | ||
| * @privateRemarks | ||
| * By using loadRuntime2 instead of loadRuntime, this prevents mixinAttributor's overriding of loadRuntime from affecting this new API: |
Contributor
Author
There was a problem hiding this comment.
This is not a change in implementation, but rather documenting a potentially confusing consequence of how this was implemented. I'm unclear if this was desired/intended, but I figured making it more clear would be good.
Contributor
Bundle size comparisonBase commit: Notable changesNo bundles changed by ≥ 500 bytes parsed. Per-bundle deltas
|
CraigMacomber
changed the title
CraigMacomber
marked this pull request as draft
July 14, 2026 16:35
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.
Description
This reworks the
@internalstaticContainerRuntime.loadRuntimeto accept a caller-providedIFluidDataStoreRegistryinstead of rawregistryEntries, converging it with the existingContainerRuntime.loadRuntime2(which already takes anIFluidDataStoreRegistry).Previously
loadRuntimeconstructed aFluidDataStoreRegistryfromregistryEntriesinternally and then delegated toloadRuntime2. This change moves that construction up into the publicloadContainerRuntimewrapper, so the two static entry points now share a single registry model.What changed:
ContainerRuntime.loadRuntimenow takesOmit<LoadContainerRuntimeParams, "registryEntries" | "runtimeOptions">plusregistry: IFluidDataStoreRegistry(and internalruntimeOptions), and simply forwards toloadRuntime2. Thenew FluidDataStoreRegistry(...)construction moves up intoloadContainerRuntime.loadContainerRuntime/loadContainerRuntimeAlphaentry points are unchanged (they still takeregistryEntriesand build the registry for you). Only the internal static API changed, so there are no API report changes and no changeset is included.ContainerRuntime.loadRuntimeAPIVersionmarker so that@fluidframework/test-utils— which calls this internal API across multiple package versions and can't special-case on package version — can detect whichloadRuntimesignature a givenContainerRuntimeexposes.loadRuntimeto match the new signature:mixinAttributor(@fluid-experimental/attributor) now wraps the incomingIFluidDataStoreRegistry(interceptingget()to inject the attributor factory) rather than appending toregistryEntries;createTestContainerRuntimeFactory(@fluidframework/test-utils) andreplayFluidFactories(@fluidframework/replay-tool) are updated as well, along with the affected unit and layer-compat tests.Motivation
This is a self-contained cleanup factored out of #27078 ("Introduce Unified API for Fluid Client").
What this change buys is convergence: it moves the older
loadRuntime— and everything built on it (mixinAttributor,test-utils,replay-tool) — onto the sameIFluidDataStoreRegistrymodel thatloadRuntime2and the newServiceClientalready use. Without it, #27078 would leave behind two parallelloadRuntimevariants with different registry models. As the code comment notes, once these callers are aligned theregistryEntries-basedloadRuntimecan eventually be removed andloadRuntime2renamed back toloadRuntime.Reviewer Guidance
The review process is outlined on this wiki page.
@internalstaticContainerRuntime.loadRuntime; the publicloadContainerRuntime/loadContainerRuntimeAlphasignatures and all API reports are unchanged, so no changeset is included — please confirm you agree this needs no changeset.loadRuntimeAPIVersionmarker plus the@fluidframework/test-utilsupdate handle the cross-version compatibility this internal, layer-compat-relevant API requires; feedback on that approach is welcome.