O servidor responde, mas a aplicação funciona?

Vamos descobrir juntos

1. 1

   Abra /healthz e /readyz com o kit funcionando. /healthz devolve um sinal fixo do processo. /readyz consulta a tabela missions e inclui o rótulo da versão somente quando a consulta funciona.

2. 2

   Leia tests/deployment.rs. O teste cria seu próprio banco em memória, remove a tabela e verifica as respostas. Essa falha não atua sobre missions.db. Não execute DROP TABLE no banco do seu projeto para imitar o teste.

3. 3

   Antes de executar o teste abaixo, preveja os códigos HTTP após a falha: /healthz ainda 200; /readyz 503. Execute e compare com as asserções. O corpo de erro não mostra SQL, caminho do banco nem missão.

4. 4

   Um diagnóstico útil diz sintoma, hipótese, teste e evidência. “Banco indisponível” é melhor que tentar reiniciar tudo sem observar. Não cole logs com informações pessoais; o teste usa apenas dados fictícios.

5. 5

   A consulta de prontidão não prova envio de e-mail, autorização ou todas as escritas futuras. Registre exatamente o que ela cobre. Um monitor periódico também precisa de intervalo e limites adequados.