Proper way to handle OperationCancelled

[sylverek]

Hello,

I am having a hard time handling OperationCancelled and couldn't find any documentation.

I realized that once I start working on workspaces with 100+ files and make quick modifications, the server throws OperationCancelled and need to restart.

node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "Symbol(OperationCancelled)".] {
  code: 'ERR_UNHANDLED_REJECTION'
}
[Info  - 3:58:53 PM] Connection to server got closed. Server will restart.

I have a few questions:

1. My understanding is this is thrown by the interruptAndCheck due to a new request. Is this correct?
2. I can't find the right way and place to handle/catch that. I tried in a few places (such as the document-builder) but without much luck. Is there any recommendation?
3. Am I missing something?
4. Finally, is there an option to debounce the requests to reduce processing required by the server? Don't think there is but thought I'd still ask.

Thank you all!

[msujew]

Hey @sylverek,

I'm wondering where this error is thrown (and not caught). Can you share a reproducible example with us? Normally, all operations that can throw this error are either run through the MutexLock or language server where they are caught and handled.

Maybe debugging the language server with the "Uncaught Exceptions" breakpoint toggled could help narrowing down the problematic areas of the code.

[sylverek]

Indexing, i.e. here? That should be handled by the mutex lock without ever throwing.

Yes, that indexing.

Maybe you're missing an await somewhere?

Going to double check and make sure I haven't.
But not sure why this would happen even with the DefaultScopeComputation though.

[msujew]

No scope computation will ever catch the error. So it really doesn't matter whether you're using your own scope computation or the default. All errors are caught on caller site of the DocumentBuilder.

[sylverek]

Alright, let me give you a little more context.

I was facing performance issues on large workspaces and decided to better understand buildDocuments() by timing each step.
I created my own customDocumentBuilder to override buildDocuments() and surround each step/call to runCancelable with console.time(...) and console.timeEnd(...). Tried using console.profile() and console.profileEnd() but it wasn't as easy to read the results.
I then configured my module to use that custom DocumentBuilder following the approach found in the langium-sql project (1 2 3 4).

The only code in my custom DocumentBuilder is the following:

protected override async buildDocuments(
    documents: LangiumDocument[],
    options: BuildOptions,
    cancelToken: CancellationToken
  ): Promise<void> {
    // 0. Parse content
    //  parsing is done initially for each document, but
    //  re-parsing after changes reported by the client might have been canceled by subsequent changes, so re-parse now

    console.time("Parsing");

    await this.runCancelable(documents, DocumentState.Parsed, cancelToken, (doc) =>
      this.langiumDocumentFactory.update(doc)
    );
    console.timeEnd("Parsing");

    // 1. Index content
    console.time("Indexing");

    await this.runCancelable(documents, DocumentState.IndexedContent, cancelToken, (doc) => {
      this.indexManager.updateContent(doc, cancelToken);
    });
    console.timeEnd("Indexing");

    // 2. Compute scopes
    console.time("Computing");
    await this.runCancelable(documents, DocumentState.ComputedScopes, cancelToken, (doc) =>
      this.computeScopes(doc, cancelToken)
    );
    console.timeEnd("Computing");

    console.time("Linking");
    // 3. Linking
    await this.runCancelable(documents, DocumentState.Linked, cancelToken, (doc) => {
      this.serviceRegistry.getServices(doc.uri).references.Linker.link(doc, cancelToken);
    });
    console.timeEnd("Linking");

    // 4. Index references
    console.time("Indexing2");

    await this.runCancelable(documents, DocumentState.IndexedReferences, cancelToken, (doc) => {
      this.indexManager.updateReferences(doc, cancelToken);
    });
    console.timeEnd("Indexing2");

    // 5. Validation
    console.time("Validation");
    const validateDocs = documents.filter((doc) => this.shouldValidate(doc, options));
    await this.runCancelable(validateDocs, DocumentState.Validated, cancelToken, (doc) =>
      this.validate(doc, cancelToken)
    );
    console.timeEnd("Validation");
  }

And this is when things started to crash.
So I removed the console.time(...) and console.timeEnd(...), same problem. Went back to the DefaultDocumentBuilder, problem gone!
The server would crash and restart on every keystroke.

Any idea why? I am pretty sure I am doing something wrong somewhere but I can't figure out what ...

[msujew]

Oh, ok that's a neat issue. So basically, what the runCancellable method expects is a function that returns maybe a promise that can be potentially caught. However, if you pass in (doc) => { this.indexManager.updateContent(doc, cancelToken); } the return value is simply void, as the function is not async. The updateContent will create it's own async-await chain that cannot be caught by the language server lifecycle. The following two will work:

// Don't create a new block, this will automatically return the result of `updateContent` from the lambda
await this.runCancelable(documents, DocumentState.IndexedContent, cancelToken, (doc) => 
      this.indexManager.updateContent(doc, cancelToken);
);

// Create an async function that awaits the `updateContent` method call
await this.runCancelable(documents, DocumentState.IndexedContent, cancelToken, async (doc) => {
      await this.indexManager.updateContent(doc, cancelToken);
});

You have the same issue in the linking phase and the reference indexing phase.

[sylverek]

Thank you, @msujew ! Completely missed that.

Now I was able to properly profile my solution and realize that the linking phase takes forever 😅 Going to work on that next!

[spoenemann]

We could add a logging feature with multiple levels (the usual error / warn / debug) and enable document builder timing when debug logging is on. Shall we create an issue for that?

[sylverek]

Great idea. I am sure a lot of people would enjoy this feature.