The goimports code makes no attempt to return a consistent set of results, so some randomness is expected when there are many candidates with equal prioritization. But these don't have equal priorities.

The problem is that when it scans the disk, it scans in priority order. But the cache iteration is in a random order, and gopls cancels the iteration as soon as it gets some number of results. There's currently no attempt to keep receiving results until it gets them at a high enough priority. I'm not sure what to do about this; the cache can't know priorities because it's not dependent on the go.mod, so we'd have to scan the entire cache, which could be slow. (We could stop after receiving "enough" hits at the highest priority, but generally speaking that won't happen.)

I'm not sure what to do about this.

The problem is that when it scans the disk, it scans in priority order. But the cache iteration is in a random order, and gopls cancels the iteration as soon as it gets some number of results.

Is there a way to change the cache iteration order? Or to at least have it prefer the local module? It seems to me you're much more likely to be looking for a package in your module.

Forgot a trick, mailed https://golang.org/cl/226559 which should improve things significantly. We can revisit if there's more complaints. I can't think of any more quick fixes.

Haven't looked at the complete-ness of the results at all yet.

With current master (including patch mentioned above) I'm still getting import reorgs that are horribly wrong.

For example, we use github.com/stretchr/testify/assert, yet writing assert.Equal(t, a, b) in a test and saving will have an import added to some other random package that isn't in our project's go.mod or in go.sum, such as gotest.tools/assert, or some random package that's not in go.mod but is in go.sum, such as gopkg.in/go-playground/assert.v1.

As for autocompletion, if I just type assert. (when it's not yet imported), the top symbols offered are from the right package, but then if I start typing Equal, it will suggest functions from the wrong package as the top hits.

Why can't the import reorg simply check each candidate against go.mod?

The imports-on-save path doesn't rank by module relevance; that's #36077.

If you already use testify in your project, it should be at the top of the rankings, because it should be in memory. I think the behavior in your screencast is simply be a scoring bug -- untyped completions are ending up before typed completions, which really shouldn't happen. @muirdm might have a guess here. I can try to reproduce it at some point, it might be pretty easy, but I don't have time right now.

Why can't the import reorg simply check each candidate against go.mod?

In general the answer to any question of the form "why can't X just Y" is going to be that it's harder than you think it is. I went into some detail above. If you want a full explanation of the architecture of the autocomplete feature, I would appreciate you asking more politely.

I looked briefly and all unimported packages seem to have a relevance of 3, which is the lowest score. github.com/stretchr/testify/assert should have a relevance of 6 if it is a direct dependency of the main module.

Change https://golang.org/cl/231238 mentions this issue: internal/lsp/source: improve unimported package member ranking

The CL above didn't fix Rebecca's issue, but I don't want to leave this open as a magnet for every ranking complaint, so I'm inclined to leave it closed for now.

Oops. I was working off @atombender's comment which I now realize does not overlap with the original items in this issue. I think the other unimported package issue you were working on should fix 2. It doesn't seem to be prioritizing packages in my module above packages in my module cache..

We should mark completion results with unimported completions in them incomplete

All completion results are marked as incomplete if you have deep completions or fuzzy matching enabled. Not sure what was going on here. Do you have the rpc trace?

I was working off @atombender's comment

Apologies. It's often hard to know some behaviour is the same issue. My own completion problem sounded to me like what this issue described.