Langium 3 and ERR_UNHANDLED_REJECTION

[cdietrich]

i see this when starting our vscode langium based extension updated to langium 3x.

node:internal/process/promises:288
            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'
}
Thrown at:
    at getErrorWithoutStack (node:internal/process/promises:320:15)
    at generateUnhandledRejectionError (node:internal/process/promises:340:15)
    at processPromiseRejections (node:internal/process/promises:286:24)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)

do you have any hints on how to analyze?

i can see interruptAndCheck does throw the symbol. but where should this be catched and handled?

[msujew]

@cdietrich Everything that is able to throw this error runs inside of the document builder, which in itself runs inside of the WorkspaceLock. The workspace lock however, handles all errors that are caught inside of it without ever throwing itself.

It might be an error similar to here where a missing await prevented the workspace lock from catching the error. Are you sure that you always await any potential throwing operation?

[msujew]

i wonder if bundlers have problems with duplicate symbols. we use esbuild

Yes, symbols are unique pointers. If you somehow manage to duplicate a symbol, performing a === will fail against the duplicated one. We use esbuild ourselves though and haven't encountered this issue yet.

[msujew]

@cdietrich I assume that your package manager somehow duplicated the langium package and it's now getting bundled twice into your app. See evanw/esbuild#475 (comment). Esbuild should tell you where these duplicated packages come from in the bundled code.

[cdietrich]

we have one project where we have the language and bundle the module (with langium)
and then a second project that uses the bundle from 1 and also uses langium.
naively this should work. but i need to check.
maybe we also need to build 2 different bundles in 1

[cdietrich]

fixing our esm bundle not to include langium solved the problem. we will bundle it in csm only now.