Fluid Container Lifecycle and States

[dstanesc]

Issue Category

• Insufficiently documented topic

Details

This issue is describing an insufficiently documented topic related to IFluidContainer lifecycle and the relevance of the associated states.

The originating observation is the evidence that under high load there is a substantial eventual consistency gap for new clients joining the container. The requirement for our solutions is to display 0 catch-up operations when a new client is opened on a container with finalized state independent of the prior system load. This is regarded as an important usability topic and there is confidence among our engineers that most of the solutions would have similar needs. We attach a movie describing the behavior and the initial workaround.

We could later find snippets of the needed information at few locations in the existing documentation:

• summarizer/#what-do-i-need-to-know
• recipes/collaborative-text-area/#code-the-project

hence recommending now to our implementation teams following code:

const [container, containerId] = await getTinyliciousContainer(...);

await waitForFullyLoaded(container);
    
// where 
function waitForFullyLoaded(container: IFluidContainer) {
    if (container.connected) {
        return;
    }
    return new Promise((resolve) =>
        container.once("connected", () => resolve(undefined))
    );
}

Our Suggestion to FluidFramework Team

To consistently mention the operation catch-up problem and the solution pattern in:

• Containers documentation / lifecycle section
• Reference above section in the Summarizer / What do I need to know?
• Include it in the example code from @fluid-example/hello-world

[tylerbutler]

The originating observation is the evidence that under high load there is a substantial eventual consistency gap for new clients joining the container.

@dstanesc I'm a little confused about what you mean here. When you say "substantial eventual consistency gap" are you saying that the newly joining client does not converge to a consistent state with the rest of the clients? Or are you referring to the operations that have accrued between the latest snapshot (which the new client loads) and the current time (the "gap")?

The requirement for our solutions is to display 0 catch-up operations when a new client is opened on a container with finalized state independent of the prior system load.

I'm unclear if you're asking for a change in behavior in the framework or just a documentation clarification that, at container load, there may be unsummarized operations that will be played back on newly joining apps to bring them up to date with the other clients.

I don't fully understand the difference between the loading case and the "in collaboration session" case. That is, if clients A and B are in-session, and client A creates (unsummarized) ops 1-10, then client B will see very similar behavior as client C will see when they join the session. Both clients B and C will "play back" ops 1-10. Is there a difference I'm not noticing?

[dstanesc]

@tylerbutler Sorry for the confusion, it is my failure in expressing our people concerns.

1. This is just a documentation enhancement needed by our engineers.
2. The new client will properly converge to the consistent state (no bug on FF side), and yes I am referring to the operations being accrued between the latest snapshot (which the new client loads) and the current time (the "gap") which will continue to be displayed until consistency reached. The FF documentation mentions loosely what needs to be done during initialization (and this is what current request is basically asking for to become more emphasized in the documentation) in Summarizer # What do I need to know? but without any code examples:

When users with significant latency use your application, they may see the state of the container at the summary and then see new operations get applied. This can be hidden by waiting for the Container to be fully connected or you can allow users to see recent changes.

Our engineers found the documentation and code examples on initializing the container and waiting to catch-up all operations already committed into the runtime insufficient. Hence this documentation enhancement request.

The short movie (see the movie link in the Details section) should illustrate better than words the UI experience without code waiting for the "connected" event.

Please let me know if my answer brings more clarity on our request.

Thank you!

[tylerbutler]

@dstanesc Thanks for the clarification. I think I know what you're looking for now. Would you or someone on your team be willing to code review doc changes here to make sure we've addressed it properly?

[dstanesc]

@tylerbutler We can definitely help with the code review. Thank you very much for the pro-activeness!

[markfields]

At first glance, some of this is related to #7995 so assigning myself here as well.

[markfields]

Unassigning myself for sprint planning/tracking purposes but still following!

[taylorsw04]

@curtisman I'm wondering if one of our teams should pull this into next sprint. Perhaps @Abe27342 would be a good candidate here?

[taylorsw04]

@skylerjokiel as well.

[microsoft-github-policy-service[bot]]

This PR has been automatically marked as stale because it has had no activity for 60 days. It will be closed if no further activity occurs within 8 days of this comment. Thank you for your contributions to Fluid Framework!