Make getPendingState synchronous when not closing

[anthony-murphy]

Background

This change is in preparation for allowing consumers of fluid to call serialize on a container while a container is in an attaching state, which will include a failed attach where the failure didn't cause the container to close. This will aid in the case of offline, network, or server outage by allowing the application to capture the un-attached state of the container, preserve it locally, and later create a new file from it.

AB#5502

Overview

To capture pending local state while the container is attaching, we will reuse the existing infrastructure which allows capturing pending local state when the container is attached. The missing piece between the detached format and the attached format which is needed for attaching is the pendingRuntimeState. The pendingRuntimeState is returned by the runtime being hosted by the container:
FluidFramework/packages/common/container-definitions/src/runtime.ts#L91

The current implementation of getPendingLocalState in the ContainerRuntime class is a bit complicated, as it offers two different modes for being called which are determined by the passed in props. The props primarily determine the behavior of dealing with blob uploads, which applications use for things like images and videos. In all cases all pending ops are captured.

If the props specify, notifyImminentClosure as true, the ContainerRuntime transitions to an offline state, and short circuits all existing blobs uploads, and waits for their handles to become referenced. This ensures that we can capture both inflight blob contents, and the ops that reference those blob contents within the application’s object model. This is the mode used by the currently experimental closeAndGetPendingState on IContainer. To accomplish this, getPendingLocalState will return a promise that will be complete once all blobs are referenced. There is also a stopBlobAttachingSignal property on the prop object which can be used to stop waiting, and only capture those blobs which have been referenced.

When notifyImminentClosure is undefined or false getPendingLocalState ignores inflight blob uploads, and only capture ops and referenced blobs. This is the mode used by the currently experimental getPendingLocalState on IContainer. Today this also returns a promise, but it is not necessary as all the work can be done synchronously.

As discussed above, we want to reuse the existing serialize method on IContainer to capture pending state while attaching. This method is currently and should remain synchronous, and we will want to reuse getPendingLocalState without notifyImminentClosure, which currently only does synchronous work, but still returns a promise.

1. Change the ContainerRuntime’s implementation IRuntime.getPendingLocalState to only return a promise if notifyImminentClosure is true and allow synchronous usage via serialize for getting pending ops.
2. Split IRuntime.getPendingLocalState into two methods. One that waits for pending work to finish, and is async, one that
   synchronously captures complete work.

While option 1 increases complexity within the function itself, it does not increase the current API surface area, as it changes behavior only. We can also mitigate this complexity by testing to validate the differing behaviors. This makes option 1 a preferable option, as the current polling-based mechanism for getting pending local state is not the long-term vision. The long-term vision is to move everything to a push-based model that allows incrementally captures local state as it is created. Adding yet another method, as option 2 would require, would further expose and entrench the polling-based model.

AB#7106

[msfluid-bot]

Could not find a usable baseline build with search starting at CI 602b981

Generated by 🚫 dangerJS against e3f6fe1

[dannimad]

Really cool way to make the method synchronous!

[dannimad]

I really like this test pattern for getPendingLocalState. I think we can do something similar to simplify all our stashed op tests

[dannimad]

I mean, it won't be a replacement for current stashed op tests but I can see us duplicating some coverage and using it more in subsequent tests

[dannimad]

LGTM!