Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make flushMode immutable and remove all tracking of it #10930

Merged
38 commits merged into from
Jul 25, 2022

Conversation

kian-thompson
Copy link
Contributor

@kian-thompson kian-thompson commented Jun 30, 2022

AB#393 and AB#394

Description

The setFlushMode API is not currently used and enables a set of scenarios which should not be supported. Maintaining this API is costly, and it adds a non-trivial amount of complexity to the adjacent logic.

Because the flushMode should no longer change, the PendingStateManager should not track the switches in the previous system. Instead, the PendingStateManager will track and replay batches explicitly rather than through the setting of flush modes.

See #9480 and #9481.

Does this introduce a breaking change?

The setFlushMode has been removed from IContainerRuntimeBase. Please remove all usage of this method as FlushMode is now an immutable property for the container runtime, optionally provided at creation time via the IContainerRuntimeOptions interface.

The PendingStateManager no longer tracks flush mode as it is now an immutable property on the IContainerRuntimeBase. Instead, tracking of batches is done explicitly and they are replayed directly through usage of the orderSequentially method on IContainerRuntimeBase.

Other information or known dependencies

TODO after this PR:

  • Add tests to improve batch coverage in containerRuntime.spec.ts. See comment.
  • Deprecate IContainerRuntime.flush. This method should not be exposed publicly.

BREAKING.md Outdated Show resolved Hide resolved
BREAKING.md Outdated Show resolved Hide resolved
}

public flush(): void {
public flush(isImmediateBatch: boolean = false): void {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it public only because pending state manager needs to call it? Can we make it private and provide it through delegation of some sort?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it would be great to have small comments on when this API is supposed to be called and what it means for this workflow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

flush has been deprecated and will be removed in AB#1076

@@ -2071,6 +2025,10 @@ export class ContainerRuntime extends TypedEventEmitter<IContainerRuntimeEvents>
} finally {
this._orderSequentiallyCalls--;
}

if (this.flushMode === FlushMode.Immediate && this._orderSequentiallyCalls === 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it !this.currentlyBatching() ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially had it as !this.currentlyBatching() but thought explicitly showing the condition is much clearer

* If the FlushMode is Immediate, we don't need to track an explicit flush call because every message is
* automatically flushed. So, flush is a no-op.
*/
if (!isImmediateBatch && this.flushMode === FlushMode.Immediate) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this check be moved out to container runtime layer? It feels like this layer (if possible) should just track batches and ops and not care about flush modes. I.e. it's responsibility of container runtime layer to convert its API surface to a stream of batches and ops (illumining flattening nested orderSequentially calls)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's for another set of refactoring :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@vladsud vladsud left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI - I only briefly looked through the code

Copy link
Contributor

@andre4i andre4i left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor comments.

Some of the code deserves some sort of state transition diagram attached to it, but that's a comment for a lot of areas in there.

Great job, BTW. This is awesome 👍 👍

BREAKING.md Outdated Show resolved Hide resolved
/**
* Flush the pending ops manually.
* This method is expected to be called at the end of a batch.
* @param isImmediateBatch - is this "flush" being called at the end of a "FlushMode.Immedite" batch?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @param isImmediateBatch - is this "flush" being called at the end of a "FlushMode.Immedite" batch?
* @param isImmediateBatch - is this "flush" being called at the end of a "FlushMode.Immediate" batch?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to expose this publicly? If we're the only ones to be calling flush with isImmediateBatch === true maybe flush with parameter can be private and the public flush will always be with false? Just trying to see if we can decrease the surface area of the API even more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine for now since flush has been deprecated. I'll revisit this in AB#1076

packages/runtime/container-runtime/src/containerRuntime.ts Outdated Show resolved Hide resolved
@kian-thompson
Copy link
Contributor Author

kian-thompson commented Jul 25, 2022

@tylerbutler Is next still protected?
Edit: I was linked the thread in Teams. Tell me if my understanding is incorrect. We use the tag to have the bot perform the merge because users could accidentally squash merge which will cause bad merge conflicts when merging to/from main.

@ghost
Copy link

ghost commented Jul 25, 2022

Hello @kian-thompson!

Because this pull request has the msftbot: merge-next label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 0ce3dd0 into microsoft:next Jul 25, 2022
@kian-thompson kian-thompson deleted the 9480-make-flushmode-immutable branch July 25, 2022 20:06
ghost pushed a commit that referenced this pull request Aug 9, 2022
[AB#1107](https://dev.azure.com/fluidframework/internal/_workitems/edit/1107)

For more information about how to contribute to this repo, visit [this page](https://github.com/microsoft/FluidFramework/blob/main/CONTRIBUTING.md).

## Description

The `PendingStateManager` should just track batches and ops and not care about the `flushMode` of the container runtime.
See #10930 (comment).
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: runtime Runtime related issues area: tests Tests to add, test infrastructure improvements, etc base: next PRs targeted against next branch breaking change This PR or issue would introduce a breaking change msftbot: merge-next public api change Changes to a public API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants