Crashes Nova in large non-Golang project

[halfnibble]

Hello.

I'm not sure if there is a simple filter that can be applied to prevent running in a non-Go repo, or exactly what is going on here, but if I enable this extension and open up a very large TypeScript codebase (tens of thousands of files), this extension will go CPU crazy and eventually crash Nova.

There are no Golang files or files with a .go extension in this project folder. Just lots and lots of TypeScript (.ts) files.

It's not a deal breaker as I can disable the extension and re-enable it when needed. Thanks for the tool!

[GwynethLlewelyn]

Oh, that's funny! Because, indeed, the Go extension should only activate when you are in a Go repo.

Or maybe not... hmm I wonder, do you have anything with the .tpl extension? Or perhaps the .mod extension?

Go's templating system tends to use .tpl files, and to use modules, Go generates a go.mod file. These are accounted for, and there are syntax highlighters for them as well. So I can imagine that if a file with one of those extensions is also used in your TypeScript project, then it might activate the Go extension...

I'll try to reproduce that... because if that's what's happening, I'll have to re-read the documentation in order to see how to turn this behaviour off. The worst-case scenario is not to detect for .tpl files at all (and ignore go.mod as well); the best solution would be to have some sort of checkbox to activate or not the Go extension for such files. I'm not even sure if that's possible at all! But I can see what I can do...

Thanks for your report!

[halfnibble]

@GwynethLlewelyn If you provide me with steps on how to determine whether or not the Go extension is running and which files it is running on, then I'll try to debug on my large TSC repo. To my knowledge there are no .mod files, but there are probably thousands of .module.scss files. There are no .tpl files.

Something is causing gopls to run hot. This repo is so large that Nova struggles to keep up with indexing files. I don't know if the extension is checking every file to see if it's a .go file, or if Nova handles that?

[GwynethLlewelyn]

Well, I don't really know how to check if an extension is running! You see, it works the other way round: AFAIK, extensions do not check files per se, they rely on the Nova host to call extensions whenever they are necessary... also, syntax highlighting etc. is supposed to be done only on the active window/tab (possibly getting cached afterwards, though), and not on files that may just happen to be around in the repo but which haven't been manually opened by the (human) user, although, again, this is a matter of speculation about the inner workings of Nova...

Once an extension is running, however, then you can check for other things... for instance, this extension checks (albeit perhaps in a clumsy way...) if gopls is running and active, and, if not, tries to launch it (I believe it only tries just once, though; the extension works without gopls for syntax highlighting, perhaps just not as well, since it falls back to Nova's 'default', non-LSP method)

In other words, I also have no clue on how to figure out if the extension is running and on which files/tabs/windows it is currently active. I guess this could be hacked somehow, by writing or listing files on an external log or something similar, but that wouldn't help you a lot. Then again, Panic has been adding more and more functionality to Nova, so possibly there are new functions which do exactly that... I would need to read about them and see what kind of thing they return.

I'm actually still struggling to find the cause of this issue. My current working assumption is that the initialisation code is not correct — possibly it's making far too many tests, most of which were sort of necessary on the earlier versions of Nova, but which might be redundant these days. I conjecture that this code might be called once per each file indexed, although, why that happens in your case but not in the tests I've made with what I considered to be a reasonably large project (with thousands of files) is still beyond my understanding. Perhaps I need to have hundreds of thousands of files to see anything go wrong — I don't know...

Just by sheer curiosity, when you open the extension console, what kind of errors do you see? There should be, in the worst-case scenario, a handful of messages for each time the extension gets activated (not run), and possibly a few errors if the extension cannot contact gopls. If you have thousands and thousands of 'extension activations', then your console ought to be swamped with those — that would be a clue towards figuring out why the extension is being activated so often, on files that have nothing to do with it. Possibly even just having millions of messages on the console is enough to crash Nova...

However, I would expect you to see just one set of messages related to the first activation of the extension. In other words, you should only see those when you deactivate and activate the extension; you shouldn't get any messages at all if the extension has been enabled but is not active, because no *.go* files are open at the moment.

[halfnibble]

So, the issue is actually in Nova most likely.
I sent some process logs over to the Nova team, and this was their response:

Thanks for the sample process report! It appears Nova's getting stuck processing the Go extension's activation events due to the sheer size of the project. We'll probably need to redesign this operation to take place off of the main thread to prevent these sorts of hangs. I've filed this with our engineers who are looking into a fix, and I'll let you know if we need any more info.

Although I'm not entirely sure why this issue pops up only for the Golang ext.
Is there any way we can configure an extension to not run in a particular workspace?