This is a minor release that includes deprecations that will take effect in a future major release as well as new features.
Deprecations
- @fluidframework/garbage-collector deprecated
- GC interfaces removed from runtime-definitions
- Some test packages no longer published
- ensureSynchronizedWithTimeout deprecated in LoaderContainerTracker
- Container-loader deprecations
- Op compression is enabled by default
- IntervalConflictResolver deprecation
@fluidframework/garbage-collector deprecated
The @fluidframework/garbage-collector
package is deprecated with the following functions, interfaces, and types in it. These are internal implementation details and have been deprecated for public use. They will be removed in an upcoming release.
runGarbageCollection
trimLeadingAndTrailingSlashes
trimLeadingSlashes
trimTrailingSlashes
cloneGCData
unpackChildNodesGCDetails
unpackChildNodesUsedRoutes
removeRouteFromAllNodes
concatGarbageCollectionStates
concatGarbageCollectionData
GCDataBuilder
getGCDataFromSnapshot
IGCResult
GC interfaces removed from runtime-definitions
The following interfaces available in @fluidframework/runtime-definitions
are internal implementation details and have been deprecated for public use. They will be removed in an upcoming release.
IGarbageCollectionNodeData
IGarbageCollectionState
IGarbageCollectionSnapshotData
IGarbageCollectionSummaryDetailsLegacy
Some test packages no longer published
These packages were previously published under the @fluidframework
scope:
@fluidframework/test-end-to-end-tests
ensureSynchronizedWithTimeout deprecated in LoaderContainerTracker
LoaderContainerTracker.ensureSynchronizedWithTimeout
is deprecated as it is equivalent to LoaderContainerTracker.ensureSynchronized
and will be removed in an upcoming release. The timeoutDuration
parameter from TestObjectProvider.ensureSynchronized
will also be removed. Please configure the timeout for the test instead.
Container-loader deprecations
The following types in the @fluidframework/container-loader package are not used by, or necessary to use our public api, so will be removed from export in the next major release:
- IContainerLoadOptions
- IContainerConfig
- IPendingContainerState
- ISerializableBlobContents
Op compression is enabled by default
If the size of a batch is larger than 614kb, the ops will be compressed. After upgrading to this version, if batches exceed the size threshold, the runtime will produce a new type of op with the compression properties. To open a document which contains this type of op, the client's runtime version needs to be at least client_v2.0.0-internal.2.3.0
. Older clients will close with assert 0x3ce
("Runtime message of unknown type") and will not be able to open the documents until they upgrade. To minimize the risk, it is recommended to audit existing session and ensure that at least 99.9% of them are using a runtime version equal or greater than client_v2.0.0-internal.2.3.0
, before upgrading to 2.0.0-internal.4.1.0
.
More information about op compression can be found here.
IntervalConflictResolver deprecation
In SharedString, interval conflict resolvers have been unused since this change, which added support for multiple intervals at the same position. As such, any existing usages can be removed. Related APIs have been deprecated and will be removed in an upcoming release.
Features
Ability to enable grouped batching
The IContainerRuntimeOptions.enableGroupedBatching
option has been added to the container runtime layer and is off by default. This option will group all batch messages under a new "grouped" message to be sent to the service. Upon receiving this new "grouped" message, the batch messages will be extracted and given the sequence number of the parent "grouped" message.
Upon enabling this option, if any issues arise, use the Fluid.ContainerRuntime.DisableGroupedBatching
feature flag to disable at runtime. This option should ONLY be enabled after observing that 99.9% of your application sessions contains these changes (version "2.0.0-internal.4.1.0" or later). This option is experimental and should not be enabled yet in production. Containers created with this option may not open in future versions of the framework.
This option will change a couple of expectations around message structure and runtime layer expectations. Only enable this option after testing
and verifying that the following expectation changes won't have any effects:
- batch messages observed at the runtime layer will not match messages seen at the loader layer
- messages within the same batch will have the same sequence number
- client sequence numbers on batch messages can only be used to order messages with the same sequenceNumber
- requires all ops to be processed by runtime layer (version "2.0.0-internal.1.2.0" or later #11832)