SharedTreeOptionsBeta Interface
Configuration options for SharedTree.
To use, import via fluid-framework/beta.
For more information about our API support guarantees, see here.
This type is "input," meaning that code outside of the library defining it should not read from it. Future versions of this type may add optional members or make typing of members more general.
Signature
export interface SharedTreeOptionsBeta extends ForestOptions, Partial<CodecWriteOptionsBeta>
Extends: ForestOptions, Partial<CodecWriteOptionsBeta>
Properties
| Property | Alerts | Modifiers | Default Value | Type | Description |
|---|---|---|---|---|---|
| healUnresolvableIdentifiersOnDecode | Beta | optional, readonly | false | boolean | When true, when an improperly encoded identifier is encountered in a summary, a new identifier will be generated instead of throwing an error. |
Property Details
healUnresolvableIdentifiersOnDecode
When true, when an improperly encoded identifier is encountered in a summary, a new identifier will be generated instead of throwing an error.
For more information about our API support guarantees, see here.
Signature
readonly healUnresolvableIdentifiersOnDecode?: boolean;
Type: boolean
Remarks
The intended use is recovering documents whose attach summary was persisted with unresolvable node identifiers (a SharedTree-attaches-to-already-attached-container scenario). Without this flag enabled, a client opening such a document will throw at summary load time. With this flag enabled, unresolvable identifiers are replaced at decode time with stable UUIDs derived deterministically from the data store id and the unresolvable op-space integer, so every reader of the same blob (other than the originator) agrees on the resulting in-memory id. Healed identifiers are written back out at the next summary in their stable UUID form, so the inconsistency does not need to be re-healed on every load.
Off by default because enabling it for documents that are not actually corrupt would mask genuine bugs that otherwise surface as decode failures.
This mitigation is also not perfect as the client that originated the non-finalized will not apply the same "healing" and will continue to use the original identifier. The difference in identifiers between the originating client and subsequent clients that load the document is not ideal but generally benign to Fluid. However, it may have application-level consequences (e.g. if the application stores the identifiers elsewhere, either in other parts of Fluid data or externally). Applications should consider whether this risk is acceptable before enabling this option.