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

Abierto
  • ¿Algo no está bien?
#129 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
rust
Área
backend

Línea de trabajo

Empieza por ServerEntry en servers_config.rs y la rama iad-native alrededor de la línea 202 de connection_pool.rs; después, compara cómo gestiona pathPrefix el código fuente de VS Code/Cursor. Sigue los puntos de entrada iris_add_server e iris_servers. La tarea está terminada cuando las entradas native puedan almacenar y exponer un prefijo web opcional y el pool lo utilice al construir la URL del servidor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).

Lenguaje dominante
Rust
Estrellas
45
Forks
17
Merge medio
2 d 11 h
PR fusionados (30 d)
15

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de intersystems-community/iris-agentic-dev

Todos los issues de intersystems-community/iris-agentic-dev

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.