Introspección y sugerencias en producción

La introspección es la parte del propio estándar que permite preguntarle al servidor por su esquema: qué tipos tiene, qué campos tiene cada tipo, qué argumentos aceptan y qué devuelven. Las herramientas de desarrollo viven de ella: con una sola petición construyen el autocompletado, generan tipos para el cliente y dibujan la documentación.

Esa comodidad tiene una lectura distinta en producción. Quien revisa una aplicación desde fuera no necesita adivinar nombres de campos ni recolectarlos de las pantallas: pide el esquema y lo tiene completo, incluidas las operaciones que nadie documentó. Apagarla no arregla ningún control de acceso —el servidor sigue resolviendo lo mismo para quien conozca los nombres—, pero sí deja de regalar el mapa a quien aún no lo tiene.

Abre el laboratorio y lee servidor-graphql.conf junto a politica-entornos.txt. Dos opciones de esa configuración no coinciden con lo que la política exige en producción. Una es la introspección; la otra es la que hace que el servidor, cuando el nombre de un campo no existe, conteste con el que más se le parece dentro de ese tipo.

En registro-errores.txt están los errores que el servidor devolvió al cliente ese día. Tres de ellos no se limitan a decir que el campo no existe: añaden el nombre correcto. Así se reconstruye un tipo entero sin introspección, un intento por vez. Mira el mensaje de las 10:14:02.

El equipo quiere cerrar el informe apagando la introspección y dando el caso por resuelto. Conviene escribir con cuidado qué cambia y qué no: lo que se gana es que el mapa deje de publicarse sin esfuerzo, lo que no cambia es quién puede leer cada campo. Un esquema se consigue también de una versión vieja de la aplicación móvil, del repositorio de un socio o, como demuestra el informe, de los propios mensajes de validación.

La política de Carretel ya dice qué debe estar encendido en cada entorno, y está bien escrita. Lo que falla es que nadie comprueba que la configuración desplegada se parezca a ella: el servidor de producción lleva encendido lo de desarrollo desde que se copió el archivo. Es un hallazgo de configuración, y se corrige donde se despliega la configuración.