New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: optimize metadata invalidation #36165
Comments
Thank you for filing a gopls issue! Please take a look at the Troubleshooting guide, and make sure that you have provided all of the relevant information here. |
I believe I observe this issue most frequently when I attempt to reference a previously unreferenced type from the imported package for the first time during a code editing session. Once that newly-referenced type is in the code, restarting gopls allows it to re-recognize the import as valid again, and it's happy to work with the code once more. |
I was able to eliminate
|
I'd probably need more logs, if not a reproducer, to make headway on this. What you're saying is consistent with gopls losing track of the low-level information ("metadata") about a package and then never trying to reload it. The first question is why it forgot about it. If you can show the logs from that point I'd be very interested to take a look. It would be surprising if simply using a symbol from that package triggered the error. More likely is adding or removing an import of it, though of course that will happen automatically. |
Thanks for the note. Sorry for not providing enough debug information - I have yet to notice a consistent set of steps for reproducing this. I also can't reproduce it consistently enough to bisect which commit may have introduced the problem. There's been a bunch of changes to gopls over the past 7 hours. I will update to current HEAD in the morning, and if the issue keeps happening, I'll turn on rpc.trace in gopls to get better logs. |
I've looked at the metadata issues a bit recently. Packages can get stuck with no metadata because metadata doesn't get fetched very often. It is basically only fetched when a package is first opened and when an import is added to a file in the package (or when a dependent package's metadata gets reloaded). So if a package's metadata is cleared for whatever reason, the package will be broken until one of the above happens to trigger metadata refetch. I've made a couple changes recently so we are more selective about invalidating metadata for the above reason. There are still some cases that probably trigger lost metadata:
It is also possible metadata gets lost due to an unlucky context cancelation. For example, we clear a package's metadata as a new import is added, but then the request is canceled before go/packages has reloaded the metadata (so we are stuck with no metadata). I played around with allowing metadata to be refreshed on-demand when we discover metadata is missing. The challenge is we don't know what to give to go/packages.Load() without the metadata. I tried adding a separate map to track each package's directory so we could reload the package's entire directory if we lose its metadata, but it didn't fix my issue at the time so I abandoned it. |
I just experienced this. I did add a new package, then used it in a few other libraries, then added tests for that new package. No I have a giant log file (some 7 MB uncompressed) that's the entire editor session from start to finish, though I'm not sure how useful it'd be. You can see "mo metadata for" logs and "no package for import" showing up at the end. |
The metadata issue after adding a test file is easily reproducible for me:
|
I'm actually not able to reproduce that behavior. Is this with modules or in GOPATH mode? |
My steps were in module mode. Below is the rpc trace. foo.go becomes broken as we get the
|
Can you share this log with verbose output enabled? I think this must be related to |
I thought that this was fixed, but I seem to have just run into this again at master ( |
I was seeing something like that before. Does it happen when you change an import in a file in the cache package? You can "fix" it by forcing a metadata refresh in source by changing an import. The details are fuzzy, but I think the issue was that reloading cache's metadata cleared out the source_test package's "cache" dependency metadata, but the only thing that fills that metadata in is loading the source package's metadata (i.e. reloading cache's metadata doesn't fill source_test's "cache" dependency metadata back in). Maybe when reloading a package's metadata we also need to trigger reloading metadata of any xtest dependents? |
Yes, it definitely seems like something a missing reverse dependency link with x_tests. Another thing I just noticed is that, specifically in |
Once we land an upgrade to the latest |
Change https://golang.org/cl/215117 mentions this issue: |
Re-opening to make sure that we optimize the metadata invalidation as discussed on the above CL. |
Change https://golang.org/cl/215901 mentions this issue: |
Since I accidentally combined two CLs and put the changes I had wanted to make into https://golang.org/cl/215902/, I'll put a description of what I had intended to do here. The intention is evident in https://golang.org/cl/215901. Previous changes tried to reduce the amount of metadata invalidated for |
Not sure if this is the right place, please direct me to the right solution/place where to raise my issue. I am able to reproduce this error in all the services I write in go, but only for the external packages (i.e. dependencies external to the service itself).
As a result, I don't have autocompletion for the packages without metadata and the editor highlights those as errors (including the related imports). |
@magandrez: Please open a new issue at https://github.com/golang/go/issues/new. It also looks like you may be using an old |
What version of Go are you using (
go version
)?go 1.13.4 (latest available in Homebrew)
Does this issue reproduce with the latest release?
Currently using gopls from
HEAD
:49a3e744
What operating system and processor architecture are you using (
go env
)?OSX
What did you do?
Normal course of editing source code
What did you expect to see?
Completions and imports of valid go packages continue to work during a development session in VSCode
What did you see instead?
Certain imports stop working partway through an edit session. Restarting the gopls server temporarily resolves the issue.
So far I have only observed this issue with code generated by protoc-gen-go, which I did update this morning; however, I must emphasize that the code is valid Go and does initially work with gopls.After an undetermined amount of time, the import lines (in all files that import it) become highlighted red for (seemingly at random) one of my generated proto files. Note that the generated file is not changing in any way during this time.
In the logs, the file that has suddenly stopped working from gopls' perspective has numerous log messages all saying the same thing: "no dep handle: no metadata for
<import path>
".I then need to restart gopls to continue working.
EDIT: removed accidental copy/pasta text
EDIT2: We do not use dep as a dependency manager; this is exclusively managed by go modules.
The text was updated successfully, but these errors were encountered: