ILoadFrozenContainerFromPendingStateProps Interface
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 interface ILoadFrozenContainerFromPendingStateProps extends ILoadExistingContainerProps
Extends: ILoadExistingContainerProps
Properties
| Property | Alerts | Modifiers | Type | Description |
|---|---|---|---|---|
| pendingLocalState | Alpha | readonly | string | Pending local state to be applied to the container. |
| readOnly | Alpha | optional, readonly | boolean | Controls whether the frozen container is surfaced as read-only. Defaults to When |
Property Details
pendingLocalState
Pending local state to be applied to the container.
For more information about our API support guarantees, see here.
Signature
readonly pendingLocalState: string;
Type: string
readOnly
Controls whether the frozen container is surfaced as read-only.
Defaults to true. When true, the container reports readOnlyInfo.readonly === true with storageOnly === true, matching the historical behavior of frozen loads.
When false, the container loads as writable so the runtime will accept DDS submissions. The connection itself stays Connected: the connection manager recognizes the synthetic frozen delta stream and drops outbound messages at the network layer, so no read→write reconnect is attempted. Local DDS state continues to update via optimistic apply, and submitted ops accumulate in the runtime's pending-state manager. Use this when callers want to accrue and capture pending state without publishing it.
For more information about our API support guarantees, see here.
Signature
readonly readOnly?: boolean;
Type: boolean
Remarks
The flag uses negative polarity (readOnly) rather than a positive opt-in (writable) to align with IContainer.readOnlyInfo.readonly, which is the established surface for read/write state on a loaded container. A future positive-polarity option can layer on top of this without breaking callers, but flipping the polarity now would split readers between two conventions for the same concept.
Subsystem behavior is unchanged from the read-only frozen path regardless of readOnly: storage operations still throw (only readBlob is supported); summarizer / id-compressor never fire because no acks arrive; the quorum is whatever was captured in pending state and gains no members during the writable-frozen lifetime. The only behavioral delta is that the runtime accepts DDS submissions and accumulates them in pendingStateManager.