microsoft/FluidFramework client_v3.7.0

Fluid Framework v3.7.0 (minor)

Repository: microsoft/FluidFramework

Tag: client_v3.7.0

Published: 2026-10-27T04:33:22Z

Prerelease: no

Release notes:

Contents

• [🌳 SharedTree DDS Changes](#user-content--sharedtree-dds-changes)
• [Reduce the bundle size of schema hashing (#28496)](#user-content-reduce-the-bundle-size-of-schema-hashing-28496)
• [Simplify the alpha schema identity API (#28496)](#user-content-simplify-the-alpha-schema-identity-api-28496)
• [Unsafe array-to-tuple conversion is available for allowed schemas (#28502)](#user-content-unsafe-array-to-tuple-conversion-is-available-for-allowed-schemas-28502)
• [Adds debug-only checks to facilitate root cause analysis of SharedTree bugs (#28435)](#user-content-adds-debug-only-checks-to-facilitate-root-cause-analysis-of-sharedtree-bugs-28435)
• [Slightly faster SharedTree initialization (#28527)](#user-content-slightly-faster-sharedtree-initialization-28527)
• [Use stable definition ordering in schema exports (#28544)](#user-content-use-stable-definition-ordering-in-schema-exports-28544)
• [Configure how much SharedTree edit history to retain (#28511)](#user-content-configure-how-much-sharedtree-edit-history-to-retain-28511)
• [🐛 Bug Fixes](#user-content--bug-fixes)
• [Binary summary blob contents can no longer include neighboring bytes in Node.js when a Buffer is a view into a larger allocation (#28485)](#user-content-binary-summary-blob-contents-can-no-longer-include-neighboring-bytes-in-nodejs-when-a-buffer-is-a-view-into-a-larger-allocation-28485)
• [Container dirty state now accounts for outstanding attachment blob work (#28459)](#user-content-container-dirty-state-now-accounts-for-outstanding-attachment-blob-work-28459)
• [Devtools ignores messages from other windows (#28503)](#user-content-devtools-ignores-messages-from-other-windows-28503)
• [Containers passed to startTelemetry are no longer kept in memory after they are disposed (#28515)](#user-content-containers-passed-to-starttelemetry-are-no-longer-kept-in-memory-after-they-are-disposed-28515)
• [TreeArrayNodes correctly handle null elements during iteration and removal (#28519)](#user-content-treearraynodes-correctly-handle-null-elements-during-iteration-and-removal-28519)

🌳 SharedTree DDS Changes

Reduce the bundle size of schema hashing (#28496)

Schema hashing uses a browser-oriented SHA-256 implementation without Node.js Buffer compatibility dependencies. This reduces browser bundle size when using `identifySchemaAlpha`.

Change details

Commit: `c98cc8b`

Affected packages:

• @fluidframework/tree
• fluid-framework

[⬆️ Table of contents](#user-content-contents)

Simplify the alpha schema identity API (#28496)

The alpha identifySchema function is renamed to `identifySchemaAlpha`. The alpha computeSchemaHash function is no longer exported. To check a schema against an expected hash, pass a schema identity to the view configuration:

const config = new TreeViewConfigurationAlpha({
schema: MySchema,
schemaIdentity: identifySchemaAlpha({ expectedHash: savedHash }),
});

If the expected hash does not match, the view construction error includes the actual hash.

Change details

Commit: `c98cc8b`

Affected packages:

• @fluidframework/tree
• fluid-framework

[⬆️ Table of contents](#user-content-contents)

Unsafe array-to-tuple conversion is available for allowed schemas (#28502)

The alpha API unsafeArrayToTuple is now exported from @fluidframework/tree/alpha and fluid-framework/alpha. It returns the original array with its type converted using `UnionToTuple`, allowing insertable content APIs to work when tuple type information has been lost. Prefer preserving the tuple type with as const when possible. The helper does not validate the array: if its element type includes a schema that is absent at runtime, TypeScript can accept content that fails at runtime.

See Why is my insertable content getting typed as `never`? for examples and an explanation of the runtime risks.

Change details

Commit: `1b88709`

Affected packages:

• @fluidframework/tree
• fluid-framework

[⬆️ Table of contents](#user-content-contents)

Adds debug-only checks to facilitate root cause analysis of SharedTree bugs (#28435)

This version adds additional runtime checks to detect errors in the rebasing (commit merging) layer. These checks can be used by application authors when faced with a SharedTree rebasing bug. For example:

import { RebaseValidation } from "@fluidframework/tree/alpha";

it("repro SharedTree bug", () => {
// Reproduce the SharedTree bug under strict rebase validation level.
RebaseValidation.runWithLevel(RebaseValidation.Level.Strict, () => {
// Buggy scenario
// ...
});
});

Running the test with strict validation is more likely to yield actionable feedback for SharedTree maintainers.

These checks are tree-shaken out of production builds, so they have no impact on shipped applications.

There are three levels of checking available:

• RebaseValidation.Level.None: No rebase validation is performed.
• RebaseValidation.Level.Cheap: A minimal amount of rebase validation is performed, with minimal performance overhead.
• RebaseValidation.Level.Strict: Extensive rebase validation is performed, with the highest performance overhead.

The level is set to RebaseValidation.Level.Cheap by default. Debug builds may therefore experience asserts in scenarios where they did not before. The level can be adjusted by calling RebaseValidation.setLevel or RebaseValidation.runWithLevel.

Change details

Commit:...