ILoadFrozenContainerFromPendingStateProps TypeAlias
Properties required to load a frozen container from pending state.
To use, import via @fluidframework/container-loader/legacy.
For more information about our API support guarantees, see here.
Signature
export type ILoadFrozenContainerFromPendingStateProps = IContainerHostProps & {
readonly pendingLocalState: string;
readonly readOnly?: boolean;
} & AllOrNone<IContainerLoadDriverProps>;
Remarks
Two forms are supported and selected by the presence of the driver-wiring fields. **Online** form supplies request, urlResolver, and documentServiceFactory; the supplied factory is wrapped in a frozen factory and the resolver is used to re-resolve the request URL just as with loadExistingContainer(loadExistingContainerProps). **Offline** form omits all three driver fields; the captured URL stored in pendingLocalState is used to synthesize a resolved URL, no real driver is contacted, and IContainer.getAbsoluteUrl throws on the returned container because the resolver's external URL format is unknown without a real IUrlResolver.
**Offline form precondition.** With no driver wiring there is no live storage to read attachment blobs from, so any blob the runtime dereferences during load must already be inlined into pendingLocalState. The pending state must therefore be produced by captureFullContainerState({ urlResolver, documentServiceFactory, request, logger, }, input) (which inlines all referenced attachment blobs) rather than IContainer.getPendingLocalState / getRequiredPendingLocalState (which do not). If the runtime needs an attachment blob that is not inlined, the load fails with UsageError from the synthesized storage service.
**URL shape requirement.** In the offline form the captured pendingLocalState.url is the only URL available; it is parsed in place of a real IUrlResolver.resolve() call, so it must satisfy tryParseCompatibleResolvedUrl(url)'s contract — a resolved URL of shape protocol://<string>/.../..?<querystring>. This is the format that Fluid-shipped drivers emit; drivers that emit a non-standard resolved-URL shape will surface as a UsageError at load time. The online form has no such constraint because the supplied resolver controls URL parsing.
The offline form supports readOnly: false for the same capture-and-relay use case as the online form: local DDS submissions accrue in the runtime's pending-state manager and can be captured via getPendingLocalState for a later online replay. Nothing is published from an offline container.
Mixing the two forms (some driver fields supplied, others omitted) is a compile-time error courtesy of the AllOrNone modifier from @fluidframework/core-interfaces.