Container issues at connection about fluidframework HOT 9 OPEN

I have created an internal bug to track this: https://dev.azure.com/fluidframework/internal/_workitems/edit/7582 to help ensure if gets fixed, but I'll attempt to keep all actual information about its status here where impacted users can see it.

from fluidframework.

The for the "AzureUser" errors, see https://github.com/microsoft/FluidFramework/releases/tag/client_v2.0.0-rc.2.0.1 : I believe that patch should fix it.

Error 0x739 is an error produced when failing to decode compressed SharedTree data. It seems your data must be corrupted somehow or there is a bug in either the encoder or the decoder. This is mostly likely a bug in shared tree: thanks for the bug report!

We have an optional validator intended to be able to be opted into to assist with debugging cases like this (to check data is well-formed when output and when parsed), but sadly there is no easy way to opt into enabling it right now. I have authored #20332 to provide a way to enable it in your app.

Combine that with

import {
	configuredSharedTree,
	typeboxValidator,
	// eslint-disable-next-line import/no-internal-modules
} from "@fluidframework/tree/internal";
const SharedTree = configuredSharedTree({
	jsonValidator: typeboxValidator,
});

and it should ideally detect if malformed data was generated, or if the data its trying to decode isn't in the right format.

Since that's not published yet, and I'd still like to try and root cause this, could you provide the data which is causing the issue?

To do so in the browser, enable breaking on caught exception and when assert 0x739 is hit, inspect the failing location with the debugger (1 up the call stack from the assert throwing the 0x739 error) and you should find a stack frame for NestedArrayDecoder.decode. In that context, evaluate JSON.stringify(stream) and provide that result. Also include the full call stack. This will include document content, so only share it here if its fine for that to be publicly posted.

Alternatively, if your application or its source are somewhere public I can run and you have a way I could reproduce the exception, I could extra that information myself.

from fluidframework.

I ran a pre-release build: 2.0.0-dev-rc.3.0.0.250606 (ex: https://www.npmjs.com/package/fluid-framework/v/2.0.0-dev-rc.3.0.0.250606) which includes #20332.

Once you use that (or a newer build) in addition to opting into additional validation to help track down the source of this bug, its possible to disable the data compression with treeEncodeType: TreeCompressionStrategy.Uncompressed which might help you avoid the bug until its fixed.

from fluidframework.

Hello,

I tried to use the internal api for debugging but it seems that this is not accessible in the pre-release build 2.0.0-dev-rc.3.0.0.250606.

Maybe I missed something.

Then I caught the error 0x739 and here is the content of the stream that trigger an error:

{ "data": [ 5, "5703557480152899", 0, "Hello", "[email protected]", 1711531476552, 1711531476552, 0, "/project/A0000023BUTIDV01", 0, 0, 0, "", false, 0, "", "" ], "offset": 16 }

I also tried the fix for the "AzurUser" errors of the 2.0.0-rc.2.0.1 version. I don't have this error anymore, but it's replaced by another issue.
When we are using the audience.getMembers(), we have a member with no data:

It seems to occur instead of the "AzurUser" error.

from fluidframework.

Hello,

I tried to use the internal api for debugging but it seems that this is not accessible in the pre-release build 2.0.0-dev-rc.3.0.0.250606.

I made a mistake. I did not realize the separate "internal" entry point is only enabled without our repo and not in public packages.
Since splitting the internal imports out into /internal is not enabled for the published package, they actually are available at the top level so this should work:

import {
	TreeCompressionStrategy,
	configuredSharedTree,
	typeboxValidator,
} from "@fluidframework/tree";
const SharedTree = configuredSharedTree({
	// Extra serialized data validation
	jsonValidator: typeboxValidator,
	// Disable tree compression
	// treeEncodeType: TreeCompressionStrategy.Uncompressed,
});

Thanks for the failing data example. I'll run that through the decoder under a debugger and see what I can figure out.

from fluidframework.

Thanks for reporting the issue. We have started the investigation and are treating this as high priority.

from fluidframework.