Rullst AcademyRullst Academy/Lección
De la aplicación a la publicación con Rullst · Lección 08 / 12

El servidor responde, ¿pero funciona la aplicación?

Una luz encendida no prueba que el robot pueda caminar. Un HTTP 200 fijo tampoco prueba que la base esté disponible.

Rutas de aprendizaje30 min

Vamos a descubrir juntos

  1. 1

    Abre /healthz y /readyz mientras funciona el kit. /healthz devuelve una señal fija del proceso. /readyz consulta la tabla missions e incluye la etiqueta de versión solo cuando funciona la consulta.

  2. 2

    Lee tests/deployment.rs. La prueba crea su propia base en memoria, elimina la tabla y verifica respuestas. Ese fallo no toca missions.db. No ejecutes DROP TABLE en la base de tu proyecto para imitarlo.

  3. 3

    Antes de ejecutar la prueba, predice los códigos tras el fallo: /healthz sigue 200; /readyz 503. Ejecuta y compara con las aserciones. El cuerpo de error no expone SQL, rutas ni misiones.

  4. 4

    Un diagnóstico útil indica síntoma, hipótesis, prueba y evidencia. “Base indisponible” es mejor que reiniciar todo sin observar. No pegues logs personales; la prueba usa solo datos ficticios.

  5. 5

    La consulta de disponibilidad no prueba envío de correo, autorización ni todas las escrituras futuras. Registra exactamente qué cubre. Un monitor periódico también necesita intervalos y límites apropiados.

Del razonamiento a la ejecución

El recorrido principal ocurre en tu equipo con datos ficticios. Podman, Quadlet y Caddy son extensiones opcionales; no necesitas comprar dominio ni contratar nube. Este laboratorio no está listo para escritura pública.

Lee los pasos antes de ejecutar. Estos comandos son una referencia; README.md explica la sintaxis de tu sistema y LAB.md reúne el recorrido. La web no ejecuta estos comandos por ti.

cargo test --locked readiness_checks_storage_and_proxy_origin_is_explicit
Mi registro de evidencias

Escribe un diagnóstico de cuatro líneas: síntoma, hipótesis, prueba, resultado. Añade algo que /readyz no comprueba para evitar exagerar la conclusión.

Separa predicción, ejecución y resultado observado. Registra “no ejecutado” cuando falte el entorno. El progreso de la web no valida una implantación real ni otorga certificación profesional.

Mis archivos y GitHub

Enlaces oficiales y siguiente paso

✦
TU MISIÓN

Comparar liveness y readiness con un fallo de almacenamiento aislado.

Ahora te toca

Taller de descubrimientos

Decide con evidencias

Tras eliminar la tabla en la base aislada de la prueba, el proceso sigue atendiendo HTTP.
Prepara tus respuestas y comprueba cuando estés listo.
Una pausa para entender

¿Por qué debe /readyz devolver 503 si falta la tabla?

Necesito una pista

Un proceso puede estar vivo sin estar listo para trabajar. La prueba aísla el fallo y verifica que la respuesta no revele detalles internos.

Cargando tu camino…

Llévatelo contigo

Escribe un diagnóstico de cuatro líneas: síntoma, hipótesis, prueba, resultado. Añade algo que /readyz no comprueba para evitar exagerar la conclusión.

A tu ritmo

Mis archivos y GitHub

Cada lección puede convertirse en un registro propio: código, notas o un plan de práctica. Guardar un archivo en GitHub es opcional y no cambia tus XP.

Manual del alumno

El editor y las descargas se abren cuando esta lección esté disponible para tu cuenta. Revisa el acceso indicado abajo o vuelve al mapa de la ruta.

Comprobando tu acceso a esta lección…

Rullstpetbot

La IA puede equivocarse. Consulta el material de la lección.