Working extension inexplicably stopped sending document symbols

I’m working on developing an extension for VSCode that utilizes this language server library. I’ve gotten to the point where I’m able to successfully respond to the onDocumentSymbol() hook. Here’s the server.ts file in my repo – a fairly simple implementation, following this guide.

However, after getting it to work in my test workspace, the “go to symbol” action then mysteriously stopped working. No indication of an error – no loading indicator, no “symbols are not available,” just “no editor symbols.”

If I enable tracing for my extension, I can clearly see the document symbol request getting sent to my language server, and then returned back to the extension client with a huge list of symbols for the file I had open.

I had made some code changes, but when I reverted all those code changes and went back to the previous state of the repo, it still did not work.

So I thought, alright, maybe there’s some config in my VSCode or something about the installation got in a weird place. So I went ahead and uninstalled VSCode completely (I’m on mac, so I deleted it from /Applications/ and also rm -rf’ed a bunch of folders as described here) and then re-installed it. I’m still getting the same behavior after re-installation.

The really vexing thing is that as soon as I try it on another computer, it still works. Just like I had it working before. I get a big list of document symbols exactly as expected.

So my question is, how do I even begin debugging this? Is there some verbose error logging I can enable? Do I need to clone this repo locally, reference it in my project, and add a bunch of console.log? Any suggestions appreciated. I’m also happy to provide more details if needed. Thanks.

[japhib]

Great, that was super helpful: looks like there was an uncaught exception on this line because of my extension returning a falsey value for aDocumentSymbol.name.

That doesn’t trigger the error handling logic below, error => client.handleFailedRequest(...), because the error occurs in the then handler rather than in the promise itself. Which also explains the behavior I was seeing where no error message would get logged or anything, the symbols just wouldn’t get populated.

I see a couple of different ways to fix – first is more specific, just adding a try/catch around the conversion code (lines 2086-2091) and call client.handleFailedRequest(...) if an error occurs.

Second would be to rewrite the handler in async/await form instead. That way you can have a try/catch around the whole thing and not duplicate calls to client.handleFailedRequest(...). That seems cleaner and more robust to me, but I don’t see many usages of async/await in this repo outside of tests – is there some aversion to it or rule against using it?

Anyways, let me know which solution would be preferable and I can put together a simple MR with the fix.

[dbaeumer]

PR is welcome.