Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

bug: v2 service discovery misses Nix-packaged OpenCode (writes service-prod.json, plugin reads service.json)

Aperta Adatta ai principianti
#336 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
lua, neovim
Ambito
tooling

Direzione di ricerca

Inizia in lua/opencode/server/discovery/init.lua, in corrispondenza di M.registration(), quindi riproduci il problema con la directory di stato XDG isolata e il pacchetto Nix descritto nell’issue. Verifica che la discovery trovi service-prod.json preservando al contempo la discovery di service.json, e conferma che :checkhealth non segnali più che non è registrato alcun servizio.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug good first issue

Summary

Server discovery only looks for service.json in the XDG state directory, but OpenCode v2 names the registration file after OPENCODE_CHANNEL. The Nix package sets OPENCODE_CHANNEL = "prod", so it writes service-prod.json and the plugin never finds a server.

Why the filename is channel-dependent

packages/cli/src/services/service-config.ts:

export function filename(channel = OPENCODE_CHANNEL) {
  if (channel === "latest" || channel === "dev" || channel === "beta" || channel === "next") return "service.json"
  return `service-${channel.replace(/[^a-zA-Z0-9._-]/g, "-")}.json`
}

So only latest, dev, beta and next produce the plain name. nix/opencode.nix on v2 builds with env.OPENCODE_CHANNEL = "prod", which is not one of them, so Nix users get service-prod.json.

lua/opencode/server/discovery/init.lua hardcodes the plain name:

local path = vim.fs.joinpath(state_dir, "service.json")

Reproduction

From a Nix-packaged OpenCode v2 (nix build .#opencode), with an isolated state dir:

$ export XDG_STATE_HOME=/tmp/oc/state
export XDG_DATA_HOME=/tmp/oc/data XDG_CACHE_HOME=/tmp/oc/cache XDG_CONFIG_HOME=/tmp/oc/config

$ opencode service start
http://127.0.0.1:49374

$ ls $XDG_STATE_HOME/opencode/
service-prod.json

$ cat $XDG_STATE_HOME/opencode/service.json
cat: .../service.json: No such file or directory

Neovim then reports, in :checkhealth opencode:

No OpenCode background service registered yet. Run opencode to start it, or set vim.g.opencode_opts.server.url.

...even though the service is running and reachable, and even after opencode has been launched from the terminal.

For comparison, the same binary built with OPENCODE_CHANNEL=latest writes service.json and discovery works:

$ export XDG_STATE_HOME=/tmp/oc2/state   # isolated again
$ opencode service start
http://127.0.0.1:49374
$ cat $XDG_STATE_HOME/opencode/service.json
{"id":"...","version":"2.0.18+dd786c6","url":"http://127.0.0.1:49374","pid":122289,"password":"..."}

Suggested fix

M.registration() should read the channel-suffixed files too, since that is what OpenCode writes. The registration payload is self-describing (url, password, pid, version), so a small glob over the state directory, newest service*.json first, would cover every channel without needing to know the channel name.

This keeps working for the channels that already write service.json, and adds the ones that do not. It also avoids tying the plugin to OpenCode's channel list, which is a separate upstream detail that can change.

Impact

Anyone consuming the Nix package (or any build that sets a channel other than latest/dev/beta/next) cannot use the plugin without hardcoding server.url and exporting OPENCODE_SERVER_PASSWORD by hand, which defeats the point of the background-service model.

Environment

  • opencode.nvim 06770e2 (main, the v2-supporting default)
  • OpenCode 2.0.18, Nix package, x86_64-linux
  • Neovim 0.11
Lingua principale
Lua
Stelle
3.8k
Fork
161
Merge medio
16h 31m
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nickjvandyke/opencode.nvim

Tutte le issue di nickjvandyke/opencode.nvim

Issue simili

Altre issue su Lua

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.