Through the debug of gopls found the objects is missing data when try many times

This repo can reproduce the problem https://github.com/pavlelee/gopls-references
https://github.com/pavlelee/gopls-references/blob/5709ea5feb28e5be021238f562d3f8a6425cb6df/models/vm.go#L5

The correct citation should be

/data/go/src/github.com/pavlelee/gopls-references/controller/references.go:11:3-5
/data/go/src/github.com/pavlelee/gopls-references/staging/src/submodule/models/vm.go:4:2-4

The problem I identified was that there were set two times filecache, first the data length of 519 was set, but last the data length of 465 was set, and 519 contained the correct object, but 465 did not. The strange thing is why the same key sets two caches of different length.
The logs for troubleshooting are as follows, the first time cache couldn't find it, so pre return true then execution post func to get correct data. the next time retry code found cache, but the cache data length was not correct(lenght 465), so couldn't find the reference correctly.：

Continue to debug, I found err: = objectpathFor (obj) code is occasionally returned this error can't find path for field Name string in github.com/pavlelee/submodule/models

Continue to investigate and find that the two objects are occasionally not equal.

Thank you for the report, and the repro and investigation. We will look into this with priority.

CC @adonovan

Thank you for the report, and the repro and investigation. We will look into this with priority.

@findleyr Thanks, it has a big impact on our project, and I really want to fix it, but I haven't figured out why the pos is different

Hmm, I can't yet reproduce with that repo. @pavlelee are you just running references repeatedly to encounter this?

In your screenshots, you have some interesting instrumentation. What does "type check data is ..." mean? When/where is that log statement added? Could you perhaps share a CL with your WIP investigation, so that we can see the instrumentation?

Ok, I can reproduce. About 1 out of every 4 attempts I can get the correct references, by clearing the cache, restarting gopls, and immediately requesting references on the ID or Name field use in controller/references.go. The timing seems to matter, which may be a clue as it could relate to making the request before the initial workspace diagnostics have completed.

I'll note that references to models.VM still do the right thing. It is only the fields that are wrong.

As I write this, I am starting to suspect that it is related to whether the import is via export data, or type-checking source. Of course the imported package loses the correct location of the forwarded field. In fact, that is almost certainly it.

Yes, that is 100% it. I just hacked up gopls to never import from export data, and the broken references is no longer reproducible.

So this is an exporter/importer bug. Unless I'm missing some complexity, we'll fix this tomorrow!

Ok, I can reproduce. About 1 out of every 4 attempts I can get the correct references, by clearing the cache, restarting gopls, and immediately requesting references on the ID or Name field use in controller/references.go. The timing seems to matter, which may be a clue as it could relate to making the request before the initial workspace diagnostics have completed.

I'll note that references to models.VM still do the right thing. It is only the fields that are wrong.

As I write this, I am starting to suspect that it is related to whether the import is via export data, or type-checking source. Of course the imported package loses the correct location of the forwarded field. In fact, that is almost certainly it.

No, the timing not to matter. The same file is set filecache twice, if the correct data (data lenght 519) is overwritten by the wrong data(data lenght 465), then there will be a problem. I don't quite understand why I set it twice.

You can set runtime.GOMAXPROCS (1) to make it easier to observe this problem.

@pavlelee the timing doesn't matter for the incorrect behavior, but to get the correct behavior you must get references before the dependent package is serialized.

I'm going to fix this in a somewhat hacky way, by changing how we compare fields in the objectpath algorithm. That should work for references, but not for other places where we rely on the canonical identity of fields.

I'll file a separate issue for the larger fix.

Change https://go.dev/cl/503438 mentions this issue: internal/gcimporter: supporting encoding objects from different packages