I have been investigating a frustrating, intermittent failure of the "Go to Definition" functionality in my editor for the past several weeks, and I believe I have finally isolated a reproducible conflict between two popular plugins. The issue manifests as a silent failure: invoking "Go to Definition" (via `gd`, `Ctrl+click`, or the LSP command) on a Go symbol sometimes does nothing—no error message, no movement, simply no observable effect. After methodically disabling plugins and observing behavior across multiple sessions, I've traced the root cause to an interaction between the **OpenClaw** file navigation plugin (version 2.8.1) and the **Go plugin** (v0.40.0, which bundles the `gopls` language server).
**Environment Details:**
* **Editor:** Neovim 0.10.0 (NVIM v0.10.0)
* **OS:** Ubuntu 22.04.3 LTS (Linux 5.15.0-94-generic)
* **Relevant Plugin List (managed via `lazy.nvim`):**
* `nvim-telescope/telescope.nvim` (with `telescope-fzf-native`)
* `mfussenegger/nvim-dap` (Debug Adapter Protocol)
* **`willothy/openclaw.nvim`** (Primary suspect)
* **`fatih/vim-go`** (with `go.nvim` for LSP configuration)
* `neovim/nvim-lspconfig`
* `hrsh7th/nvim-cmp` (LSP completion source)
**The Conflict & Repro Case:**
The failure is not consistent on every symbol or file, which made diagnosis particularly tedious. It appears to be tied to specific conditions where OpenClaw's background file indexing or its "quick open" cache mechanism overlaps with a `gopls` request. My reproducible test case involves a medium-sized Go module (~50 files) with internal package references.
1. **Normal Operation:** With *only* `nvim-lspconfig` and `vim-go` configured (OpenClaw disabled), `gopls` handles "Go to Definition" flawlessly across the entire codebase, including cross-package jumps.
2. **Failure Mode:** With OpenClaw enabled and active, performing a series of rapid "Go to Definition" actions (e.g., 5-10 jumps in quick succession) will, with high probability, result in one of the jumps failing silently. The LSP log (`:LspLog`) shows the request is sent but no subsequent response is recorded.
3. **Key Observation:** The issue is exacerbated when OpenClaw's `:Claw` fuzzy finder has been used recently in the same session. Monitoring process activity, I noted a spike in LuaJIT GC activity during the silent failures, suggesting a resource contention or a stale reference in a shared data structure.
**Tentative Root Cause Hypothesis:**
I suspect the plugins are not directly interfering but are competing for a shared resource or event loop phase. OpenClaw's non-cooperative async indexing (which does not yield control) might be blocking or delaying the LSP client's ability to process the response from `gopls` before a timeout occurs internally. The intermittent nature points to a race condition dependent on the state of OpenClaw's internal cache.
**Workaround & Questions:**
A temporary workaround is to disable OpenClaw's background indexing by setting `enable_background_scan = false` in its configuration. This reduces the failure frequency dramatically but does not eliminate it entirely, pointing to additional conflict points in the UI layer.
Has anyone else encountered similar intermittent LSP failures when using resource-intensive fuzzy-finders or file navigators alongside `gopls` or other stateful language servers? I am particularly interested in whether this is a known issue with the Neovim event loop model under specific plugin combinations, or if there are established patterns for configuring plugin concurrency to avoid such clashes.
—A.J.
Your data is only as good as your pipeline.