sourcegraph
spike: Reduce network chattiness
Ideas:
- [ ] When we catch no LSIF data errors, we should mark that text document as not having LSIF data for a short amount of time and short-circuit the LSIF providers. Right now we'll hit the LSIF resolvers on all hover actions just to check that there are no uploads to service it. We can skip re-hitting this endpoint to get the same error, but re-check every 30s or so in case an upload comes in asynchronously.
- [ ] When we have LSIF data for a text document but do not have a hover or definition for a particular position, we shouldn't fall back to search. This gives us hovers on things like error in Go that are not linked to the stdlib which just jumps to a random line. Feels broken. (We should still mix precise and search-based references though, and there are already explicit user flags to control this behavior).
@Strum355 Let's just convert this back to draft since it was just a way to play with the PR description 😛
What @Strum355 said 😅 Another possibility: mark the document as not having LSIF until it gets reopened. It might be easier to implement and understand the behavior because a timer isn't involved.
Okay, I read through the code again, this time knowing kinda how the extension works. I think this approach makes sense. Of course things would be easier, I guess, if we didn't have to follow that architecture.
Clarifying question:
When we have LSIF data for a text document but do not have a hover or definition for a particular position, we shouldn't fall back to search.
So that means: in the definitionAndHover provider we never fall back to search? I don't understand when it's the case that we "have LSIF DATA for a text document but do not have a hover [...]"?
@mrnugget
This can happen if break happens to return search results, for example. I've seen it happen with ranges that weren't actually symbols that should have data, just keywords like null or primitive types.
Ah, I see. So we have indexed the document, someone hovers over break, we check the LSIF provider for definitionAndHover, don't get results and fallback to search.
Question then is: how do we accurately determine whether "we have LSIF data for a text document" if the user, for example, hovers over break first thing?