Sinon: fakeServer est cassé avec .respond (500) sur 1.17.4

Je peux confirmer que cela se produit sur 1.17.4 mais pas 1.17.3. J'ai une configuration similaire avec karma-sinon.

Je suppose que le problème est dans ce commit https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793

La balise 1.17.4 été poussée dans le registre npm mais je n'ai trouvé aucune trace de cette balise sur ce référentiel. Que s'est-il passé?

Je suppose que la balise n'a tout simplement pas encore été créée. Il est sorti il ​​y a seulement 3 heures

@mbarlock Ouais, probablement - néanmoins je pense que ce serait mieux si le tag sur GitHub était publié en premier. Au moins, nous jetterions un coup d'œil et aiderions sur un PR ou quelque chose à corriger.

Ma faute. J'ai oublié git push --tags . Merci pour les informations sur le bogue.

Je viens de confirmer que commit 2cfbacd a définitivement fait échouer les tests pour nous dans mozilla / loop # 400.

J'ai appliqué le correctif à partir du # 1031 localement, et il corrige nos tests.

Si la 1.17.4 change le comportement existant, ne devrait-elle pas faire partie d'une nouvelle version majeure? Actuellement, il est considéré comme compatible avec la version 1.17.3, donc un package.json spécifiant une dépendance sinon comme "^ 1.17.3" obtiendra 1.17.4 et échouera potentiellement aux tests qui fonctionnaient auparavant.

La façon dont la 1.17.3 fonctionne est une régression, n'est-ce pas? N'hésitez pas à me corriger. Si tel est le cas, il doit être réparé et non maintenu dans son état cassé.

MISE À JOUR: Cela ressemble à un bogue réel.

Oh, je n'avais pas lu votre discussion originale sur https://github.com/sinonjs/sinon/pull/861 @fearphage . Il semble que ce soit le bon comportement, même si je pense que cela aura plus d'impact que prévu, étant donné la durée du bogue dans la base de code Sinon.

Compte tenu de cela, il semble que la bonne chose à faire de mon côté est de changer mes tests pour qu'ils s'appuient sur xhr.onabort au lieu de xhr.onerror. Je soupçonne que ce changement causera de la confusion pendant un certain temps, car les tests unitaires exécutés localement ne téléchargent pas automatiquement toutes les dépendances si elles sont présentes dans un répertoire node_modules, donc les gens le découvriront lorsqu'ils ajouteront de nouvelles dépendances à leur package.json (je me suis vite rendu compte car Travis CI fait une installation npm à partir de zéro pour mes tests).

Je ne sais pas quelle est la bonne marche à suivre. Peut-être ajouter une note au journal des modifications pour 1.17.4 spécifiant que certains tests qui reposent sur "onerror" devraient utiliser "onabort"? (btw, à partir de ce commentaire, http://sinonjs.org/Changelog.txt n'inclut pas encore la version 1.17.4).

Je reprends ça. J'ai cherché à corriger mes tests et j'ai réalisé qu'un nouveau bogue avait été introduit dans https://github.com/sinonjs/sinon/commit/2cfbacd5cea5b63c014076d3a65b6642b2200793 . La fonction onReadyStateChange déclenche désormais un ProgressEvent "erreur" au lieu de s'appuyer sur la fonction d'abandon pour appeler directement onerror si elle est définie. Le problème est que FakeXMLHttpRequest n'a actuellement pas d'écouteur pour l'événement "erreur".

J'ai créé PR https://github.com/sinonjs/sinon/pull/1042 pour ajouter la clé d'erreur eventListener manquante. Sans cette modification, tous les tests unitaires qui vérifient qu'une fonction de gestionnaire onerror est appelée sur une réponse d'erreur de serveur légitime (comme 500) échoueront. Faites-moi savoir ce que vous en pensez , @ fatso83

Lors de ma lecture initiale de ce fil, je n'ai pas vu https://github.com/sinonjs/sinon/pull/1041 , qui ajoute la clé eventListener manquante et du code supplémentaire pour affirmer l'ordre des événements. N'hésitez pas à ne pas tenir compte de mon PR si vous optez plutôt pour cela.

OK, # 1041 (identique à # 1042) a maintenant été fusionné.

@overcaffeinated Concernant le

Des trucs comme celui-ci me donnent vraiment envie de sortir le 2.0 pour ne pas investir trop d'énergie dans la branche 1.x.

1.7.4 a fait échouer plusieurs de mes tests. Pensons-nous que 1.7.5 résoudra cela?

Malheureusement, cela ne résoudra pas le problème pour tout le monde, car # 1031 n'est pas encore corrigé. Je vais essayer de vous aider ce soir.

Merci pour l'info, @ Standard8 !

J'ai corrigé (cassé?) Ceci basé sur mon interprétation de la spécification XHR. Ce serait bien s'il y avait une implémentation de navigateur à laquelle comparer cela pour s'assurer que c'est bien cette fois. Nous avons besoin d'un banc de test pour comparer la fausse implémentation xhr de sinon à la réalité pour nous assurer que les événements se déclenchent dans le bon ordre et que les événements corrects sont déclenchés.

N'importe quels preneurs?

@fearphage une idée à quoi ressemblerait un tel banc d'essai? une suite de tests manuels? un peu difficile à simuler "réseau en panne" dans les navigateurs normaux. donc je ne sais pas vraiment comment cela devrait être fait.

J'imagine que ce serait comme browsercope.org ou du moins il pourrait l'utiliser comme backend pour stocker les résultats.

Imaginez cependant http://www.acidtests.org/ pour XHR

Voici quelques utilitaires basés sur les requêtes pour vous aider:

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

Cela semble être d'excellentes ressources! Browserscope est en panne, btw.

@fearphage Je n'ai pas eu le temps de trouver comment www.browserscope.org , alors j'ai créé une page Web à la place:

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

Charge les dernières versions de Firefox, Chrome, IE et Safari.

@ Standard8 Je l'apprécie. Je l'utilise pour comparer la fausse implémentation de serveur de sinon. Merci.

@fearphage @ fatso83 , pourriez-vous nous donner un aperçu de l'état actuel de ce problème?

D'un rapide survol, il semble que nous devrions envisager de revenir à la fonctionnalité v1.17.3 et de fournir une version v1.17.5 - même si l'ancienne fonctionnalité était cassée, cela représente un changement de rupture de l'API et devrait donc être intégré à la version 2.0?

Je pense que vous l'avez bien résumé, bien que @fearphage soit plus dans les détails de celui-ci. Je continue à être submergé en essayant de garder en tête ce qu'il y a dans la branche v1.17 et ce qu'il y a dans master . Je pense que la plupart des problèmes ont été corrigés dans master , mais je ne pense pas que cela soit valable pour la branche v1.17 (qui n'a pas de correctifs tels que # 1031 et # 1041 AFAIK). Je me trompe peut-être (probablement).

Je pense que la solution la plus pragmatique pourrait être de faire ce que vous avez dit:

• Revert # 1017 (et connexe?) pour que la branche 1.17 réduise le bruit et garde l'API réseau identique, expédie une version 1.17.5 et accepte simplement que l'implémentation est moins correcte que dans la version 2
• conservez les modifications dans master et documentez simplement ce qui a changé dans le guide de migration (voir # 1090).

Je suis juste en train de rattraper ce qui se passe ici. Serait-il préférable de réparer que de revenir en arrière?

Le plus gros changement est lorsque error / onerror est viré ou non, non?

@fearphage Merci de votre participation! Puisque je suis plutôt lent, pourriez-vous s'il vous plaît faire un résumé en cinq lignes des changements d'API qui seraient apparents du point de vue d'un utilisateur final existant lorsque tous les correctifs ont été appliqués à la branche v1.17?

Alors que de gros changements seraient acceptables pour une nouvelle version majeure, tout ce qui commence à casser de nombreux tests dans 1.x devrait probablement être suspendu, mais je n'étais tout simplement pas sûr que ces correctifs qui ont été appliqués à master réglerait la plupart des problèmes rencontrés par les gens avec la version 1.17.4.

Pour autant que je sache, la seule chose qui ne fonctionne pas est que les requêtes non-200 devraient toujours déclencher des événements error . Y a-t-il plus à cela? Je crois que tout ce dont il a besoin, ce sont les correctifs du maître.

Cela semble être une bonne idée d'extraire v1.7.4 de Github et NPM également. La plupart des gens le rétablissent ou ne peuvent pas le mettre à niveau.

Si tout cela a changé, je suggérerais simplement d'inclure les correctifs qui sont entrés dans master et d'envoyer une version 1.17.5 dès que possible. Pourriez-vous le faire? Je pars en vacances ( Date.now() ).

Comme la suppression des versions de NPM n'est pas considérée comme très "sympa", j'ai émis une commande npm deprecate pour la 1.17.4. Je ne suis pas sûr non plus de supprimer la balise, si certaines personnes s'y fient. C'est une autre discussion, cependant, et je suggère que nous nous concentrions sur l'envoi du correctif.

Ça ma l'air bon. Je devrais pouvoir y arriver ce week-end.

J'ai une solution proposée à ce problème si quelqu'un veut peser sur # 1102.

Si quelqu'un en a besoin, j'ai un peu modifié le fichier de test de @ Standard8 et c'est ce que j'ai utilisé pour rapprocher le faux xhr du comportement du navigateur.

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

@ Standard8 Merci encore! :taper:

Selon la spécification, un événement d'erreur n'est déclenché que lorsqu'un événement au niveau du réseau comme un délai d'attente DNS ou un serveur non réactif se produit. 500 ou 404 ne sont que des réponses HTTP normales et c'est à une application de décider si une erreur s'est produite. https://www.w3.org/TR/XMLHttpRequest/#event -xhr-error
La spécification est trop concise comme d'habitude. Les réponses non 2xx sont considérées comme des erreurs par jQuery, c'est pourquoi de nombreuses personnes sont déroutées par le comportement de XMLHttpRequest.

@ nyk0r : c'est à peu près ce que fait le correctif de Phred :)

@gil : cela devrait être corrigé par l'excellent travail de @fearphage dans # 1102, # 1108 et # 1109. Comme votre cas de test est incomplet (pas de contrôle / vérification), voudriez-vous vérifier qu'il a bien été corrigé par le code de la branche v1.17 actuelle? Si vous le faites, nous pouvons expédier une nouvelle version de correctif dès que possible.

Alternativement, @wlepinski ou @mbarlock pourrait peut-être vérifier que cela a été corrigé dans la branche v1.17 ? Changez simplement la dépendance sinon dans package.json pour lire: sinon#v1.17 pour utiliser la bonne branche directement depuis GitHub.

OK, vérifié pour être corrigé en exécutant ce test:

"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);
}

Cela ne fonctionnait pas avec la version 1.17.4, mais avec les derniers correctifs.

Il s'avère que @fearphage a déjà couvert ce test dans bf709a7f (ligne 1797), mais bon ...

Fermeture comme fixe.

Malheureusement, je n'ai plus accès à ce projet pour le tester, je travaille maintenant dans une nouvelle entreprise. Mais je leur ferai savoir, au cas où ils voudraient mettre à jour la bibliothèque. Merci pour le correctif !!