extension moduel getLocalExtHostExtensionService blocked

[coyzeng]

No description provided.

[kaisalmen]

@coyzeng Please take your time to describe your problem properly.

[OliverwengFiltered]

I'm having the same issue after upgrading the monaco-languageclient to v6.5.1. (it builds/bundles successfully though)

did some debugging with break points on the front end. It looks like the getLocalExtHostExtensionService call promise in vscode/extensions.js never successfully resolve so the code doesn't hit line 39. (this call is triggered on initServices function under root monaco-languageclient lib, and because of this, the initServices promise never gets resolved.)

any insights? @kaisalmen

[kaisalmen]

@CGNonofr do you have an idea?
@OliverwengFiltered can you reproduce this with our local webpack verification example?

[CGNonofr]

Was initializeExtensions called?

[kaisalmen]

This should ensure it:
https://github.com/TypeFox/monaco-languageclient/blob/main/packages/client/src/monaco-vscode-api-services.ts#L27-L41
It is called at line 32.

[OliverwengFiltered]

was doing some debugging, the code I was showing is inside the initializeExtensions call.

the above initialize function is this function as @kaisalmen pointed out, it's the bundled version.

and then I stepped into it, got the below image, and it stuck at the highlighted line and never got to the next line.

[samirzubi-db]

I am having the same issue as above where getLocalExtHostExtensionService promise does not resolve or reject.

[kaisalmen]

@OliverwengFiltered and @samirzubi-db are you using @codingame/monaco-vscode-theme-defaults-default-extension? Please try to await the whenReady before initializing your own extension, like here:
https://github.com/TypeFox/monaco-languageclient/blob/main/packages/examples/src/python/client/main.ts#L90

@CGNonofr I have the suspicion it is related to this:
#544 (comment)

[samirzubi-db]

@kaisalmen thanks for the quick response I am not using @codingame/monaco-vscode-theme-defaults-default-extension. I am only calling initialize from vscode/services and then the initialize from vscode/extensions. I am not using any service overrides since I need only the default ones.

[kaisalmen]

@samirzubi-db or @OliverwengFiltered can you publish a reproducible example / repo somewhere? I can't reproduce what you see. I assume you cannot reproduce this with the examples from this repo or can you?

[coyzeng]

@samirzubi-db or @OliverwengFiltered can you publish a reproducible example / repo somewhere? I can't reproduce what you see. I assume you cannot reproduce this with the examples from this repo or can you?

https://github.com/coyzeng/monaco-example.git

[coyzeng]

[kaisalmen]

@coyzeng @OliverwengFiltered @CGNonofr thank you, whatever react does provokes the issue. I don't know why, yet.

When I move the init code to your main and comment the react usage the init works as expected:

const initMlc = async () => {
    await initServices({
        debugLogging: true
    });
};
console.log(0)
initMlc();
console.log(1)

// const root = ReactDOM.createRoot(document.getElementById('root')!);
// root.render(<SQLEditor/>);

Can it be that using useEffect provokes the problem?

[CGNonofr]

Wasn't it called too late? (after the editor creation/default services instantiation)

[kaisalmen]

Wasn't it called too late? (after the editor creation/default services instantiation)

It works until, I put the render function back in

[kaisalmen]

Is it Monday again?! I don't see a fundamental difference in our react example.

[kaisalmen]

The actual problem is not react, but defining monaco.editor.defineTheme directly in an import file (@github). If wrap that in an exported function and call it at a proper place. Everything works.

[kaisalmen]

Sorry, closed this to quickly. @OliverwengFiltered should verify/comment if it is the same issue.

[samirzubi-db]

I had the same issue with the theme being declared directly. Thank you for looking into this @kaisalmen and @coyzeng for the repro!

[CGNonofr]

I'll add a check in the monaco-vscode-api service initialization to make sure the services aren't already initialized to prevent such confusing issues

[OliverwengFiltered]

well, that did not solve my issue on my end. I will put together a sample project to reproduce in a few hours.

[kaisalmen]

well, that did not solve my issue on my end. I will put together a sample project to reproduce in a few hours.

Thank you.

[OliverwengFiltered]

Hi @kaisalmen and @CGNonofr

I have uploaded a public repo to reproduce the issue: https://github.com/OliverwengFiltered/monaco-test

simply follow the below steps to reproduce.

1. clone the repo.
2. npm install.
3. npx webpack build
4. npm start.
5. visit localhost:3000
6. the editor should load.
7. now go to monacoInit.js and uncomment those lines.
8. now start server again, you will see a blank state.

curious why calling Editor.getModels() will prevent the editor from being rendered with latest version. (same code is not painting blank state with monaco-languageclient v6.4.6)

[CGNonofr]

monaco.editor.getModels() initializes the services as well

[OliverwengFiltered]

@CGNonofr ok, so which api method should I use to check if it has been initialized or not ?

[OliverwengFiltered]

so in this case, @CGNonofr
if I have to do dispose() before editor's creation. any recommendations?
it seems currently, the Editor.getModels() and LanguageClientLib.initServices() are both initialize monaco services, and they can't co-exists in the new 6.5.2 version. And the check wasVscodeApiInitialized() returns false even if Editor.getModels() are called before hand.

[CGNonofr]

I think wasVscodeApiInitialized only returns true if it was initialized using the initServices method

You just need to wait for the service to be initialized before calling getModels

[OliverwengFiltered]

that makes sense, @CGNonofr .

and I can confirm that calling LanguageClientLib.initServes() function before the .getModels function works.

Thanks, we can close this ticket now.

Thanks all.

[kaisalmen]

Wonderful. 🎉