Not summarizing on first connection

[arinwt]

There seems to be an issue where the first connection to a document isn't summarizing.

Maybe related to detached creation flow?

Reproduce by creating a new Fluid document (or collaborative meeting) and enter some text. Wait 15+ seconds, and then refresh. It will not have summarized.

[leeviana]

Also determined to not be caused by snapshot caching as this repros with multiple refreshes if you don't give it time to summarize in between.

[curtisman]

I was writing unit test for the "leader" event and noticed an odd behavior that the container created using detached creation would lose the leadership immediately by AgentAcheduler.clearRunningTasks in AgentScheduler.initialize() when the AgentScheduler transition from detached to attached state.

        if (this.runtime.attachState === AttachState.Detached) {
            this.runtime.waitAttached().then(() => {
                this.clearRunningTasks();
            }).catch((error) => {
                this.sendErrorEvent("AgentScheduler_clearRunningTasks", error);
            });
        }

So the first created container never becomes a leader. That may be why the summarizer never ran. This results in new document doesn't summarize without reloading or have other client join the session. @jatgarg re: detached create flow

[curtisman]

After debugging further, I think it is a problem with the AgentScheduler itself, not necessary specific to detached create flow. In the detached create flow case, it is correct yp lose leadership when trying attach the container to storage. But the bug is that the leader isn't being reassign back after attach.

The problem with with how AgentScheduler clean up the value in the consensus collection. With multiple client, the task's clientId is clean up by other clients on removeMember event from the quorum. The last client doesn't clean up themselves, and rely on the next client that connect to clean it on when the AgentScheduler is reloaded (in AgentScheduler.initiallizeCore). The cleanup of the value is done after the attempt of reassignment of the task.

In the detached create flow case, AgentScheduler go thru multiple state transition when we attach the container (disconnect and then connect), and after some op is sent to get the container out of "view only" mode, the runtime finally connect. The AgentScheduler is then be receive the connect event and be active and call AgentScheduler.initializeCore again. However at that time, the clientId for the leader task is still assigned to the last clientId, and we won't reassign it again.

[vladsud]

@curtisman, leader election is not used in determination of summarizer. It is not a consensus process, it's calculation process (oldest client in quorum is a summarizer). So bug in AgentScheduler is not affecting summarizer (and this issue)

[curtisman]

Yep. Jump to conclusion too quickly. this is unrelated.

[curtisman]

@arinwt I am not able to repro this directly in app itself. After creating a new document and type something, it always summarize after 15s (seeing GenerateSummary*, SummaryOp/SummaryAck messages using localStorage.debug="fluid:*").

Is there other repro step I should try?

[leeviana]

I reproed this in OWA with the meeting notes flow. I created a new meeting notes section, waited for document attach, typed and waited 15 seconds+ after for a summary to happen.

Then I closed and reopened the same meeting over and over again. As long as I didn't leave the new meeting open for 15 seconds (which would have triggered another summary because OWA now adds an op on reopen), I could easily see that the collab space was replaying ops from document attach onward - no summary was taken.

[vladsud]

I'd recommend to leave it longer (up to a minute) and see what happens. In my testing I quite often see summaries taking longer than 15 seconds for completely idle clients. It's possible that some ops are sent here and there that delay the timer (without any user interaction). As a general statement, system does not provide any specific guarantee for when summaries are running.

[leeviana]

I had left it up to a minute and more :) I have also tested on subsequent loads that after typing and waiting 15 seconds that a summary DID happen.

[leeviana]

I saw similar behavior in Teams as well and verified by using teams.microsoft.com with debugPurple = 1 filter logs by 'summary'. Waited for much more than 15 seconds and nothing came in.

[curtisman]

I have tested with OWA (meetings), Teams on the Web (chat and meetings) and the editing apps. All seems to summarize around 15s mark. All of them shows version 0.31.1. I worked with @leeviana to repo, and she was able to repro with version 0.29 of the loader, but once it updated to 0.31 it doesn't repro either. Seems the issue has been fix I will close this for now.