Sinon: fakeServer está quebrado com .respond (500) em 1.17.4

Posso confirmar que isso acontece em 1.17.4, mas não em 1.17.3. Eu tenho uma configuração semelhante com o karma-sinon.

Meu palpite é que o problema está neste commit https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

A tag 1.17.4 foi enviada para o registro npm, mas não encontrei nenhum vestígio dessa tag neste repositório. O que aconteceu?

Meu palpite é que a tag ainda não foi criada. Só foi lançado há 3 horas

@mbarlock Sim, provavelmente - no entanto, acho que seria melhor se a tag no GitHub fosse lançada primeiro. Pelo menos daríamos uma olhada e ajudaríamos em um PR ou algo para consertar.

Foi mal. Esqueci git push --tags . Obrigado pela informação sobre o bug.

Acabei de confirmar que o commit 2cfbacd definitivamente causou a falha dos testes para nós no mozilla / loop # 400.

Eu apliquei o patch de # 1031 localmente e ele corrige nossos testes.

Se 1.17.4 muda o comportamento existente, não deveria fazer parte de uma nova versão principal? Atualmente, ele é considerado compatível com 1.17.3, portanto, um package.json especificando uma dependência sinon como "^ 1.17.3" obterá 1.17.4 e possivelmente falhará nos testes que funcionavam.

A maneira como 1.17.3 funciona é uma regressão, certo? Sinta-se à vontade para me corrigir. Se for esse o caso, deve ser consertado e não deve ser mantido em seu estado quebrado.

ATUALIZAÇÃO: parece um bug real.

Oh, eu não tinha lido sua discussão original em https://github.com/sinonjs/sinon/pull/861 @fearphage . Parece que esse é o comportamento correto, embora eu ache que terá mais impacto do que o pretendido, considerando há quanto tempo o bug está na base de código do Sinon.

Considerando isso, parece que a coisa certa a fazer da minha parte é alterar meus testes para confiar em xhr.onabort em vez de xhr.onerror. Suspeito que esta mudança causará confusão por um tempo, já que os testes de unidade executados localmente não baixam novamente todas as dependências se estiverem presentes em um diretório node_modules, então as pessoas descobrirão sobre isso quando adicionarem novas dependências a seus package.json (percebi rapidamente porque o Travis CI faz uma instalação npm do zero para meus testes).

Não tenho certeza de qual é o curso de ação correto. Talvez adicionar uma nota ao changelog para 1.17.4 especificando que alguns testes que dependem de "onerror" devem usar "onabort"? (btw, a partir deste comentário, http://sinonjs.org/Changelog.txt ainda não inclui 1.17.4).

Retiro o que eu disse. Eu tentei consertar meus testes e percebi que um novo bug foi introduzido em https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 . A função onReadyStateChange agora dispara um "erro" ProgressEvent em vez de depender da função de abortar para chamar onerror diretamente, se definido. O problema é que FakeXMLHttpRequest atualmente não tem um ouvinte para o evento "erro".

Criei PR https://github.com/sinonjs/sinon/pull/1042 para adicionar a chave eventListener de erro ausente. Sem essa mudança, qualquer teste de unidade que verifique se uma função de manipulador onerror está sendo chamada em uma resposta de erro de servidor legítima (como 500) falhará. Deixe-me saber sua opinião, @fearphage @ fatso83

Na minha leitura inicial deste tópico, não vi https://github.com/sinonjs/sinon/pull/1041 , que adiciona a chave eventListener ausente e o código extra para declarar a ordem dos eventos. Sinta-se à vontade para desconsiderar minhas relações públicas se preferir isso.

OK, # 1041 (igual a # 1042) agora foi mesclado.

@overcaffeinated Em relação ao changelog ausente que é devido a uma falha no script de compilação dos documentos que me impediu de atualizá-los (consulte https://github.com/sinonjs/sinon/issues/991#issuecomment-216651347). Me desculpe por isso. Esperamos que possamos fazê-lo funcionar novamente e adicionar uma observação sobre a mudança.

Coisas como essa me fazem realmente querer lançar o 2.0 para que não invistamos muita energia no branch 1.x.

1.7.4 fez com que vários dos meus testes falhassem. Esperamos que 1.7.5 resolva isso?

Infelizmente, isso não corrigirá para todos, pois o número 1031 ainda não foi corrigido. Vou tentar ajudar ao longo desta noite.

Obrigado pela informação, @ Standard8 !

Consertei (quebrei?) Isso com base na minha interpretação da especificação XHR. Seria bom se houvesse uma implementação de navegador para comparar para ter certeza de que está certa neste momento. Precisamos de um teste para comparar a implementação xhr falsa do sinon com a realidade para garantir que os eventos sejam disparados na ordem correta e os eventos corretos sejam disparados.

Qualquer comprador?

@fearphage, alguma ideia de como seria esse ambiente de teste? um conjunto de testes manuais? meio difícil de simular "rede inativa" em navegadores normais. portanto, não tenho certeza de como isso deve ser feito.

Eu imagino que seria como browserscope.org ou pelo menos poderia usar isso como backend para armazenar os resultados.

Imagine http://www.acidtests.org/ para XHR embora

Aqui estão alguns utilitários baseados em solicitação para ajudar:

https://httpbin.org/
http://requestb.in/

Parecem recursos excelentes! O Browserscope está desativado.

@fearphage Eu não tive tempo para descobrir como colocar algo em www.browserscope.org , então criei uma página da web em vez disso:

http://people.mozilla.org/~mbanner2/sinonXHRBrowserTest.html

Carrega nas últimas versões do Firefox, Chrome, IE e Safari.

@ Standard8 Agradeço. Tenho usado isso para comparar a implementação de servidor falso do sinon. Obrigada.

@fearphage @ fatso83 , você poderia fornecer uma visão geral do status atual deste problema?

Em uma rápida olhada, parece que devemos considerar reverter a funcionalidade v1.17.3 e fornecer uma versão v1.17.5 - mesmo que a funcionalidade antiga tenha sido quebrada, isso representa uma alteração de API de interrupção e, portanto, deve ser implementado na versão 2.0?

Acho que você resumiu bem, embora @fearphage esteja mais interessado em detalhes sobre este. Eu sempre fico confuso tentando segurar na minha cabeça o que está no branch v1.17 e o que está em master . _Acho_ que a maioria dos problemas foi corrigida em master , mas não acho que isso seja válido para o branch v1.17 (que não tem correções como # 1031 e # 1041 AFAIK). Posso estar (provavelmente estou) enganado.

Acho que a solução mais pragmática pode ser fazer como você disse:

• reverter # 1017 (e relacionado?) para o branch 1.17 para reduzir o ruído e manter a API da rede a mesma, enviar uma versão 1.17.5 e apenas aceitar que a implementação é menos correta do que na versão 2
• mantenha as alterações em master e apenas documente o que mudou no guia de migração (consulte # 1090).

Estou apenas atualizando o que está acontecendo aqui. Seria melhor consertar do que reverter?

A maior mudança é quando error / onerror é demitido ou não, certo?

@fearphage Obrigado por participar! Como sou bastante lento, você poderia fazer um resumo de cinco linhas de quais mudanças de API seriam aparentes do ponto de vista de um usuário final existente quando todas as correções tivessem sido aplicadas ao branch v1.17?

Embora grandes mudanças sejam aceitáveis ​​para uma nova versão principal, qualquer coisa que comece a quebrar muitos testes em 1.x provavelmente deve ser suspensa, mas eu não tinha certeza se essas correções que foram aplicadas a master resolveria _maioria_ dos problemas que as pessoas estão tendo com o 1.17.4.

Pelo que entendi, a única coisa quebrada é que as solicitações diferentes de 200 ainda devem acionar eventos error . Existe mais nisso? Acredito que tudo de que precisa são as correções do mestre.

Parece uma boa ideia retirar v1.7.4 do Github e do NPM também. A maioria das pessoas o está revertendo ou não pode atualizá-lo.

Se tudo isso mudou, eu sugeriria apenas incluir as correções que foram feitas em master e enviar uma versão 1.17.5 o mais rápido possível. Você poderia fazer isso? Estou saindo de férias ( Date.now() ).

Como a remoção de versões do NPM não é considerada muito "legal", emiti um comando npm deprecate para 1.17.4. Também não tenho certeza sobre como remover a tag, se algumas pessoas estão contando com ela. Essa é outra discussão, no entanto, e sugiro que nos concentremos em enviar a correção.

Soa como um plano. Devo conseguir chegar neste fim de semana.

Tenho uma proposta de solução para esse problema se alguém quiser avaliar o número 1102.

Se alguém precisar, modifiquei um pouco o arquivo de teste de @ Standard8 e é isso que tenho usado para aproximar o xhr falso do comportamento do navegador.

https://dl.dropboxusercontent.com/u/2400/tc/sinon/xhr-browser-test.htm

@ Standard8 Obrigado novamente! :aplaudir:

De acordo com a especificação, o evento onerror é disparado apenas quando ocorre um evento de nível de rede, como um tempo limite de DNS ou servidor que não responde. 500 ou 404 são apenas respostas HTTP normais e cabe a um aplicativo decidir se ocorreu um erro. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
A especificação é muito concisa, como de costume. Respostas não 2xx são consideradas erros por jQuery, é por isso que muitas pessoas ficam confusas com o comportamento de XMLHttpRequest.

@ nyk0r : isso é basicamente o que a correção de Phred faz :)

@gil : isso deve ser corrigido pelo excelente trabalho de @fearphage em # 1102, # 1108 e # 1109. Como seu caso de teste está incompleto (sem verificação / verificação), você se importaria em verificar se ele realmente foi corrigido pelo código no branch v1.17 atual? Se você fizer isso, podemos enviar uma nova versão de patch o mais rápido possível.

Alternativamente, @wlepinski ou @mbarlock podem verificar se isso foi corrigido no branch v1.17 ? Basta alterar a dependência sinon em package.json para ler: sinon#v1.17 para usar o branch correto diretamente do GitHub.

OK, verificado para ser corrigido executando este teste:

"call load handler on non-2xx statuses" : function(){
  var stub = sinon.stub();
  this.xhr.addEventListener("load", stub);
  this.xhr.open("GET", "/");
  this.xhr.send();

  this.xhr.respond(500, { 'Content-Type' : 'application/json' }, JSON.stringify({}));
  assert(stub.called);
}

Isso não funcionou com 1.17.4, mas funciona com as correções mais recentes.

Acontece que @fearphage já cobriu este teste em bf709a7f (linha 1797), mas ei ...

Fechamento corrigido.

Infelizmente não tenho mais acesso a esse projeto para testá-lo, estou trabalhando em uma nova empresa agora. Mas vou avisá-los, caso queiram atualizar a biblioteca. Obrigado pela correção !!