x/tools/gopls: issues many redundant go list invocations concurrently #81408

Activity

1. gopherbot

   added

   ToolsThis label describes issues relating to any tools in the x/tools repository.This label describes issues relating to any tools in the x/tools repository.

   goplsIssues related to the Go language server, gopls.Issues related to the Go language server, gopls.

   on Sep 9, 2026
2. gopherbot

   added this to the Unreleased milestone on Sep 9, 2026
3. pjweinb commented on Sep 10, 2026

   

   pjweinb

   on Sep 10, 2026

   More actions

   Thanks for the report. gopls is likely creating new snapshots too rapidly, and cancels with a 5 second delay. (and i wonder if the whole descendant process group should be killed, as go list spawns jobs)

   Some things that might help:
   Debounce in didChangeWatchedFiles so multiple changes would result in only a single new snapshot?
   golang.org/x/sync/singleflight.Group for go list invocations?
   reduce maxInFlight, as go list already tries to use all the cpus?

   We need to think about it.
4. hyangah

   modified the milestones: Unreleased, gopls/backlog on Sep 10, 2026
5. hyangah

   assigned

   pjweinb

   on Sep 10, 2026
6. gopherbot commented on Sep 10, 2026

   

   gopherbot

   on Sep 10, 2026

   Contributor

   More actions

   Change https://go.dev/cl/830824 mentions this issue: internal/gocommand: kill process group on cancel
7. gopherbot commented on Sep 10, 2026

   

   gopherbot

   on Sep 10, 2026

   Contributor

   More actions

   Change https://go.dev/cl/830844 mentions this issue: gopls/internal/server: debounce didChangeWatchedFiles
8. gopherbot commented on Sep 11, 2026

   

   gopherbot

   on Sep 11, 2026

   Contributor

   More actions

   Change https://go.dev/cl/830884 mentions this issue: gopls/internal/cache: serialize package reloading
9. tagawa0525 commented on Sep 12, 2026

   

   tagawa0525

   on Sep 12, 2026

   Last edited by gabyhelp

   More actions

   A measurement on CL 830844 patch set 2 (dacbdbd80), cherry-picked onto 249605012, against 249605012 itself, both built with go1.27.0 linux/amd64. Two-file module: a.go with func Target() {} (open in the editor), b.go with func Caller() { Target() } (not open). A client over stdio removes the call from b.go on disk, sends workspace/didChangeWatchedFiles (Changed) for it, and immediately starts asking textDocument/references on Target every 10ms.

   Today, the first request, sent right after the notification, already answers 0 references: gopls handles the notification before the request that follows it. With the CL, the requests sent up to 40ms after the notification answer 1 reference, the call that no longer exists; the first to answer 0 is the one sent at 50ms or 60ms, once the debounce has flushed. Sending the notification 20 times 30ms apart (a burst, the case the CL is for) after putting the call back, the requests sent up to 500ms, the debounceMax, answer 0, while the file on disk has had the call the whole time; the one sent at 510ms answers 1. Two runs each, same numbers (times are send times; the requests go out on a fixed 10ms schedule regardless of when the answers arrive, and the burst notifications are sent from the same loop, a notification first when both are due at the same time).

   So the CL changes what a client can rely on: after the change, a request that follows didChangeWatchedFiles on the same connection may be answered from the snapshot before the change, and nothing tells the client which it got. The CL flushes pending changes when an editor operation arrives, to keep on-disk files and overlays ordered, but a request does not flush them. That matters most for the client that only edits on disk and then asks, which is what tools driving gopls without an editor do. The CL itself treats one such client differently: gopls mcp's fileOf now applies its file events through session.DidModifyFiles directly, bypassing the debounce, "so snapshot queries are not delayed by the debounce timer". An LSP client in the same position has no such path.

   For reference, two ways other servers coalesce work while letting a client tell what its answer reflects. pyright applies the notification at once and defers only the analysis: the watched-file change marks the file dirty synchronously and schedules the reanalysis on a timer (markFilesDirty / scheduleReanalysis in packages/pyright-internal/src/analyzer/service.ts), and in my measurement a request right after the notification answered with the new content. rust-analyzer hands the change to its VFS loader and coalesces VFS events per loop turn, but a request whose snapshot is invalidated underneath it is retried or answered with -32801 ContentModified (handlers/dispatch.rs), never from the old snapshot, and for a change that triggers a reload experimental/serverStatus reports quiescent: false and then true. In gopls terms the first pattern would be keeping the snapshot invalidation in order and coalescing only the reload; the smallest change would be draining the pending changes at the start of request handling too, as didModifyFiles does for editor operations: a burst with no request in the middle is still one modification pass, and a request in the middle costs one flush, which is what it costs today.

   Whichever way this goes, what the client above needs is to be able to tell whether a notification it sent has been applied. Today's ordering gives that implicitly. A flush on request, a ContentModified instead of an answer from before the change, or a notification when pending changes have been applied would each give it explicitly. An answer from before a change the client has already reported, with no signal, is the one outcome it cannot handle.

   The probe is scripts/gopls/health-probe.py --scenario stale-after-watched-change at https://github.com/tagawa0525/lsp-det.
10. gopherbot

    added a commit that references this issue on Oct 8, 2026

    internal/gocommand: kill process group on cancel

    ...

    1332450