@fluidframework/container-runtime 2.0.0-rc.3.0.3 → 2.0.0-rc.3.0.5

package/dist/containerRuntime.js

@@ -1244,6 +1244,7 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
         this.emitDirtyDocumentEvent = false;
         let newState;
         try {
+            this.submitIdAllocationOpIfNeeded(true);
             // replay the ops
             this.pendingStateManager.replayPendingStates();
         }
@@ -1420,9 +1421,10 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
         // We do not need to make a deep copy. Each layer will just replace message.contents itself,
         // but will not modify the contents object (likely it will replace it on the message).
         const messageCopy = { ...messageArg };
+        const savedOp = messageCopy.metadata?.savedOp;
         for (const message of this.remoteMessageProcessor.process(messageCopy)) {
-            if (modernRuntimeMessage) {
-                this.processCore({
+            const msg = modernRuntimeMessage
+                ? {
                     // Cast it since we expect it to be this based on modernRuntimeMessage computation above.
                     // There is nothing really ensuring that anytime original message.type is Operation that
                     // the result messages will be so. In the end modern bool being true only directs to
@@ -1430,12 +1432,16 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
                     message: message,
                     local,
                     modernRuntimeMessage,
-                });
-            }
-            else {
-                // Unrecognized message will be ignored.
-                this.processCore({ message, local, modernRuntimeMessage });
-            }
+                }
+                : // Unrecognized message will be ignored.
+                    {
+                        message,
+                        local,
+                        modernRuntimeMessage,
+                    };
+            msg.savedOp = savedOp;
+            // ensure that we observe any re-entrancy, and if needed, rebase ops
+            this.ensureNoDataModelChanges(() => this.processCore(msg));
         }
     }
     /**
@@ -1500,9 +1506,7 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
                 // stashed ops flow. The compressor is stashed with these ops already processed.
                 // That said, in idCompressorMode === "delayed", we might not serialize ID compressor, and
                 // thus we need to process all the ops.
-                if (!(this.skipSavedCompressorOps &&
-                    messageWithContext.message.metadata?.savedOp ===
-                        true)) {
+                if (!(this.skipSavedCompressorOps && messageWithContext.savedOp === true)) {
                     const range = messageWithContext.message.contents;
                     // Some other client turned on the id compressor. If we have not turned it on,
                     // put it in a pending queue and delay finalization.
@@ -1631,9 +1635,9 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
         let checkpoint;
         let result;
         if (this.mc.config.getBoolean("Fluid.ContainerRuntime.EnableRollback")) {
-            // Note: we are not touching this.pendingAttachBatch here, for two reasons:
-            // 1. It would not help, as we flush attach ops as they become available.
-            // 2. There is no way to undo process of data store creation.
+            // Note: we are not touching any batches other than mainBatch here, for two reasons:
+            // 1. It would not help, as other batches are flushed independently from main batch.
+            // 2. There is no way to undo process of data store creation, blob creation, ID compressor ops, or other things tracked by other batches.
             checkpoint = this.outbox.checkpoint().mainBatch;
         }
         try {
@@ -2378,9 +2382,11 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
         this.verifyNotClosed();
         return this.blobManager.createBlob(blob, signal);
     }
-    submitIdAllocationOpIfNeeded() {
+    submitIdAllocationOpIfNeeded(resubmitOutstandingRanges = false) {
         if (this._idCompressor) {
-            const idRange = this._idCompressor.takeNextCreationRange();
+            const idRange = resubmitOutstandingRanges
+                ? this.idCompressor?.takeUnfinalizedCreationRange()
+                : this._idCompressor.takeNextCreationRange();
             // Don't include the idRange if there weren't any Ids allocated
             if (idRange?.ids !== undefined) {
                 const idAllocationMessage = {
@@ -2442,32 +2448,7 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
                         referenceSequenceNumber: this.deltaManager.lastSequenceNumber,
                     });
                 }
-                // If this is attach message for new data store, and we are in a batch, send this op out of order
-                // Is it safe:
-                //    Yes, this should be safe reordering. Newly created data stores are not visible through API surface.
-                //    They become visible only when aliased, or handle to some sub-element of newly created datastore
-                //    is stored in some DDS, i.e. only after some other op.
-                // Why:
-                //    Attach ops are large, and expensive to process. Plus there are scenarios where a lot of new data
-                //    stores are created, causing issues like relay service throttling (too many ops) and catastrophic
-                //    failure (batch is too large). Pushing them earlier and outside of main batch should alleviate
-                //    these issues.
-                // Cons:
-                //    1. With large batches, relay service may throttle clients. Clients may disconnect while throttled.
-                //    This change creates new possibility of a lot of newly created data stores never being referenced
-                //    because client died before it had a change to submit the rest of the ops. This will create more
-                //    garbage that needs to be collected leveraging GC (Garbage Collection) feature.
-                //    2. Sending ops out of order means they are excluded from rollback functionality. This is not an issue
-                //    today as rollback can't undo creation of data store. To some extent not sending them is a bigger
-                //    issue than sending.
-                // Please note that this does not change file format, so it can be disabled in the future if this
-                // optimization no longer makes sense (for example, batch compression may make it less appealing).
-                if (this.currentlyBatching() &&
-                    type === messageTypes_js_1.ContainerMessageType.Attach &&
-                    this.disableAttachReorder !== true) {
-                    this.outbox.submitAttach(message);
-                }
-                else if (type === messageTypes_js_1.ContainerMessageType.BlobAttach) {
+                if (type === messageTypes_js_1.ContainerMessageType.BlobAttach) {
                     // BlobAttach ops must have their metadata visible and cannot be grouped (see opGroupingManager.ts)
                     this.outbox.submitBlobAttach(message);
                 }
@@ -2599,7 +2580,13 @@ class ContainerRuntime extends client_utils_1.TypedEventEmitter {
                 this.channelCollection.reSubmit(message.type, message.contents, localOpMetadata);
                 break;
             case messageTypes_js_1.ContainerMessageType.IdAllocation: {
-                this.submit(message, localOpMetadata);
+                // Allocation ops are never resubmitted/rebased. This is because they require special handling to
+                // avoid being submitted out of order. For example, if the pending state manager contained
+                // [idOp1, dataOp1, idOp2, dataOp2] and the resubmission of dataOp1 generated idOp3, that would be
+                // placed into the outbox in the same batch as idOp1, but before idOp2 is resubmitted.
+                // To avoid this, allocation ops are simply never resubmitted. Prior to invoking the pending state
+                // manager to replay pending ops, the runtime will always submit a new allocation range that includes
+                // all pending IDs. The resubmitted allocation ops are then ignored here.
                 break;
             }
             case messageTypes_js_1.ContainerMessageType.ChunkedOp: