Introduce a new FlushMode in the interest of not creating too many batches

[andre4i]

Description

When the client uses async code, there is a risk of creating too many batches (enough batches to trigger server-side throttling) as with FlushMode.TurnBased as flush is scheduled as a microtask. This change allows for flushing to happen in a scheduled macrotask, capturing all the ops from all microtask and bundling them as a single batch.

[msfluid-bot]

⯆ @fluid-example/bundle-size-tests: -606 Bytes

Metric Name	Baseline Size	Compare Size	Size Diff
aqueduct.js	430.62 KB	430.44 KB	⯆ -180 Bytes
connectionState.js	680 Bytes	680 Bytes	■ No change
containerRuntime.js	225.58 KB	225.4 KB	⯆ -180 Bytes
loader.js	158.96 KB	158.96 KB	■ No change
map.js	43.95 KB	43.87 KB	⯆ -82 Bytes
matrix.js	136.13 KB	136.05 KB	⯆ -82 Bytes
odspDriver.js	91.07 KB	91.07 KB	■ No change
odspPrefetchSnapshot.js	42.43 KB	42.43 KB	■ No change
sharedString.js	156.67 KB	156.59 KB	⯆ -82 Bytes
Total Size	1.36 MB	1.36 MB	⯆ -606 Bytes

---

Baseline commit: 2aebc74

Generated by 🚫 dangerJS against a70cfa3

[vladsud]

I think you can have most of these changes in main, with exception of this change in enum.
I.e. you can easily have

export enum FlushModeEx {
Async = 2,
};

and use it in main, and merge FlushModeEx & FlushMode in next

[andre4i]

How would that work? Can you expand a bit? The runtime would still expect FlushMode | FlushModeEx in its APIs, right? Isn't that still a back-compat breaking change?

[vladsud]

No, everywhere in the code I'd keep FlushMode alone.
If caller (Loop) wants to experiment, then can do FlusModeEx.timeout as FlusModeEx.
And the only place where we need to do cast is switch:

switch (mode) {
case FlushMode.immidiate:...
case FlushModeEx.timeout as FlushMode:

}

This adds ability to push most of the code into main (which is good think from all points), while not changing officially API, but allowing (if we want to) experimentation.

[andre4i]

I will prepare the change for main

[andre4i]

#14106

[andre4i]

Ok, so the plan is to merge #14106 first, then wait for main->next integration and afterwards I'll re-adjust this PR to accommodate the changes from main. My goal is to make it so that we don't end up with merge conflicts and at the same time, next uses proper flushmode.

[agarwal-navin]

Before we add this experiment, should we check that the current applications will even use this? Otherwise, we might not get any data suggesting if this even works.

[microsoft-github-policy-service]

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!