Should users whitelist any specific urls while using Liveshare?

[RichieMcCaff]

Specifically why I'm asking this is we have a user using our liveshare app that gets stuck infinitely loading.
Digging deeper into this we can see they successfully create a LiveShareHost and successfully joined the Fluid container.

But then after this point every sharedState/liveState/presence never initialises and it's just sitting there waiting.
There is no error produced and we can't see any network failures either.

The reason I think this has to be something getting blocked is it used to work for them and then suddenly this started happening.
On testing sessions with them I can also see the youtube liveshare app doesn't work, they aren't aware of anything they may have done but I was hoping to find out if there is anything I can specifically tell them they should be whitelisting.

[ryanbliss]

Specifically why I'm asking this is we have a user using our liveshare app that gets stuck infinitely loading.

Digging deeper into this we can see they successfully create a LiveShareHost and successfully joined the Fluid container.

But then after this point every sharedState/liveState/presence never initialises and it's just sitting there waiting.

There is no error produced and we can't see any network failures either.

The reason I think this has to be something getting blocked is it used to work for them and then suddenly this started happening.

On testing sessions with them I can also see the youtube liveshare app doesn't work, they aren't aware of anything they may have done but I was hoping to find out if there is anything I can specifically tell them they should be whitelisting.

Strange...this isn't something I've heard of. No errors in the console? Do you have Fluid telemetry enabled to get signal-level traces? They often log it in the "Info" section, which many browsers disable by default. If you aren't seeing any logs with that enabled even when things are working well, you probably don't have it enabled.

If you can get the documentId for an impacted session (assuming it gets that far), that could help too. The fact presence and other DDS's aren't initializing would imply the container never connected, but they were able to get the container successfully. So if we get a documentId we can work with Azure to get better logs.

It's certainly possible their IT department requires whitelisting the Azure Fluid Relay web socket address. If so, it's surprising I haven't heard of this issue before...but the world of IT is all over the place.

[ryanbliss]

@RichieMcCaff there is a default logger in place, but you can define a custom one via ILiveShareClientOptions.logger. This is more useful for intercepting and logging via your app telemetry. Simple example:

import {
    ITelemetryBaseLogger,
    ITelemetryBaseEvent,
    LogLevel,
} from "@fluidframework/core-interfaces";

export class CustomLogger implements ITelemetryBaseLogger {
    send(event: ITelemetryBaseEvent, logLevel?: LogLevel) {
        if (logLevel === LogLevel.error) {
            // TODO: Send event to your server
        }
    }
}

[RichieMcCaff]

@ryanbliss Thanks, I've added the logging and will double check what comes from it.
But before that was implemented I received this containerId where the issue occured: 4f9255f2-a4cb-4b56-b4c1-92f6d3ee0f07

[ryanbliss]

@RichieMcCaff here is some additional docs on error logging in Fluid: https://fluidframework.com/docs/testing/telemetry/

Asking the Fluid team to investigate that containerId, will update once I know more.

[ryanbliss]

Got this response @RichieMcCaff:

Did a quick check on this document and it looks like there are successful server calls this morning. Any more info about what type of failures and when would be helpful.

[RichieMcCaff]

@ryanbliss Sorry for the delay, I got married and was out for the last month.
Just on the above, we have enabled telemetry logging and the single error I see coming in is the following:

{"attempts":1,"delay":1000,"eventName":"fluid:telemetry:ConnectionManager:DeltaConnectionFailureToConnect","duration":20013,"online":"Online","category":"generic","stack":"Error at m (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:425676) at Dn.createErrorObject (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:222574) at Dn.createErrorObject (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:223933) at Ur.<anonymous> (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:219707) at Wt.emit (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:155362) at Ur.onerror (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:183061) at Wt.emit (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:155362) at i (https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:189050) at https://app-ms-teams-app.prod.thriveglobal.com/327.3efbd1c94d50847a4ed8.web-ms-teams-app.js:2:189203 at r (https://app-core.prod.thriveglobal.com/thrive-web-core.js:2:174341)","error":"socket.io (connect_error): timeout","errorType":"genericNetworkError","fluidErrorCode":"-","driverVersion":"1.4.0","canRetry":true,"message":"socket.io (connect_error): timeout","errorInstanceId":"0b8ac410-071f-41a8-b40c-5f008229b75c","clientType":"interactive","containerId":"3879cd51-ed56-4473-b00b-ff449034ae28","docId":"ca9ee790-88ac-436e-a5be-0dad74eafc73","containerAttachState":"Attached","containerLifecycleState":"loaded","containerConnectionState":"Disconnected","serializedContainer":false,"dmInitialSeqNumber":0,"dmLastProcessedSeqNumber":0,"dmLastKnownSeqNumber":0,"connectionStateDuration":20013.60000000149,"loaderId":"f203720c-5450-4494-9f5f-55797a47fa18","loaderVersion":"1.4.0"}