iad-native server registry (servers.json) can't store a web-server path prefix — instances behind a gateway prefix are unreachable

Aperta
  • Qualcosa non va?
#129 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend

Direzione di ricerca

Inizia da ServerEntry in servers_config.rs e dal ramo iad-native intorno alla riga 202 di connection_pool.rs, quindi confronta come il codice sorgente di VS Code/Cursor gestisce pathPrefix. Traccia i punti di ingresso iris_add_server e iris_servers. Il lavoro è completato quando le entry native possono memorizzare ed esporre un prefisso web opzionale e il pool lo usa per costruire l’URL del server.

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

Descrizione

Disclaimer: This report was written with the help of Claude (Anthropic's Claude Code). The findings were investigated against the iris-agentic-dev source, but please verify the file/line references and suggested fix before acting.

Type: Bug / small feature gap in the 072 multi-instance-pool feature

Short description:
The iad-native server registry entry schema (ServerEntry in servers.json) has no field for the IRIS web-server path prefix (the VS Code webServer.pathPrefix / .toml web_prefix). As a result, any server whose Atelier API is served under a URL prefix — e.g. http://host:port/hs20261/api/atelier/... — cannot be registered correctly via iris_add_server. The pool builds the base URL as scheme://host:port with no prefix, so the connection points at the gateway root and never reaches the instance.

How we stumbled on it:
We're standing up two HealthShare 2026.1 instances on one host+port, distinguished only by their web path prefix (/hs20261 for UCR, /hscv20261 for Clinical Viewer) — a common HealthShare / shared-gateway layout. We wanted to register both with iris_add_server so we could target each per-call with the server param instead of hand-editing .iris-agentic-dev.toml. But iris_servers showed the existing native entry pointing at host:8080 with no prefix, and there was no field to add one. Digging into the source confirmed the schema simply doesn't carry it.

Root cause (from source):

  • servers_config.rs — ServerEntry fields are only host, port, namespace, username, description, scheme. No prefix field.
  • connection_pool.rs (~line 202, iad-native branch): let base_url = format!("{}://{}:{}", scheme, entry.host, entry.port); — no prefix segment.
  • The other pool sources already support this: the VS Code/Cursor cascade reads pathPrefix into path_prefix and appends it (~line 242), and .toml has web_prefix. So only the iad-native source drops the prefix — an inconsistency across sources of the same feature.

Impact:

  • iris_add_server produces an unreachable entry for any prefix-served IRIS (all shared-gateway HealthShare deployments, reverse-proxied setups, etc.).
  • Existing prefix-less native entries silently resolve to the gateway root.
  • Per-call server-param routing — the headline benefit of 072 — is unusable for these deployments; users are forced back to editing .toml web_prefix.

Suggested fix:

  1. Add web_prefix: Option to ServerEntry (serde skip_serializing_if = "Option::is_none"; consider accepting pathPrefix as an alias to match VS Code).
  2. In the iad-native branch of connection_pool.rs, build the prefix segment the same way the VS Code branch does and append it to base_url.
  3. Add an optional web_prefix param to iris_add_server and surface the value in iris_servers output.
  4. Back-fill / allow editing existing entries (the current hs20252 entry is unreachable as written).

Workaround for now: rewrite .iris-agentic-dev.toml web_prefix to toggle between instances (hot-reloads, no restart).

Lingua principale
Rust
Stelle
45
Fork
17
Merge medio
2g 24m
PR unite (30g)
6

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 intersystems-community/iris-agentic-dev

Tutte le issue di intersystems-community/iris-agentic-dev

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.