Bug #19949
le rendu de la cellule calendrier de réservation est synchrone
100%
Description
Il y a appel à Chrono mais sans lui dire de lever une erreur au cas où l'info ne serait pas dans le cache, le résultat c'est du coup un rendu synchrone de la cellule, et la page bloquée sur une requête à chrono.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Un patch qui prend aussi en compte #19950. (je pense que ça aurait pu être un meme ticket)
Mis à jour par Josué Kouka il y a plus de 6 ans
- Lié à Bug #19950: en cas d'erreur de récupération des événements la cellule calendrier de réservation est juste vide ajouté
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch ajouté
Rebaser sur master.
Mis à jour par Frédéric Péters il y a plus de 6 ans
Il y a beaucoup de bruit dans les tests, qui compliquent leur lecture.
Au milieu des lignes qui se trouvent ainsi changées, pourrait passer inaperçu quelque chose comme :
links = page2.html.findAll('a')
- assert len(links) == 2
- previous_page_link = links[1]
+ assert len(links) == 1
+ previous_page_link = links[0]
Qui indique un changement de comportement peut-être important; quel lien existait et a disparu ?
if not context.get('synchronous'):
raise NothingInCacheException()
Non, "NothingInCacheException" ça signifie qu'il n'y avait pas les données dans le cache; et oui c'est utilisé à mauvais escient du côté des celulles famille et factures, elles gagnent #19996 et #19997.
A priori render() devrait disparaitre et les particularités nécessaires dans le contexte de rendu de la cellule obtenues via get_cell_extra_context().
# case where the cell is in mid creation state
Il faut plutôt un is_visible(), que la cellule ne soit pas affichée du tout quand elle n'est pas configurée. (cf FeedCell par exemple).
~~
(et non je ne trouve pas approprié de mêler deux changements qui ne sont pas liés dans un seul commit).
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch ajouté
Frédéric Péters a écrit :
Il y a beaucoup de bruit dans les tests, qui compliquent leur lecture.
[...]
Concernant le bruit dans les tests:
1. L'url attaquée change. Avant on attaquait l'url de la page cette fois ci on attaque celle qui fait le chargement async.
2. Je n'utilise plus resp dans test_cell_rendering parce qu'en cas d'erreur lors de la soumission, la réponse contient le message d'erreur mais pas le contenu de la cellule car chargé de manière async.
Au milieu des lignes qui se trouvent ainsi changées, pourrait passer inaperçu quelque chose comme :
Qui indique un changement de comportement peut-être important; quel lien existait et a disparu ?
3. Avant j'avais 2 liens: le lien du titre de la page contenant la cellule et le lien next de la pagination. Vu que je tape directement sur l'url du rendu async, je n'ai plus qu'1 seul lien.
[...]
Non, "NothingInCacheException" ça signifie qu'il n'y avait pas les données dans le cache; et oui c'est utilisé à mauvais escient du côté des celulles famille et factures, elles gagnent #19996 et #19997.
Ok, modifié.
A priori render() devrait disparaitre et les particularités nécessaires dans le contexte de rendu de la cellule obtenues via get_cell_extra_context().
Oui.
[...]
Il faut plutôt un is_visible(), que la cellule ne soit pas affichée du tout quand elle n'est pas configurée. (cf FeedCell par exemple).
Done
~~
(et non je ne trouve pas approprié de mêler deux changements qui ne sont pas liés dans un seul commit).
Mis à jour par Frédéric Péters il y a plus de 6 ans
Concernant le bruit dans les tests:
1. L'url attaquée change. Avant on attaquait l'url de la page cette fois ci on attaque celle qui fait le chargement async.
2. Je n'utilise plus resp dans test_cell_rendering parce qu'en cas d'erreur lors de la soumission, la réponse contient le message d'erreur mais pas le contenu de la cellule car chargé de manière async.
De la description du ticket, le seul changement dans les tests ça devrait être en début de test charger la page, vérifier que la cellule apparait bien comme devant être chargée en asynchrone, ensuite faire le chargement asynchrone, et la suite, la reprendre sans changements aux tests, vu qu'après le chargement asynchrone l'info est dans le cache et il doit y avoir bascule sur le rendu synchrone.
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchonous-199.patch 0001-booking-calendar-make-cell-rendering-asynchonous-199.patch ajouté
Frédéric Péters a écrit :
Concernant le bruit dans les tests:
1. L'url attaquée change. Avant on attaquait l'url de la page cette fois ci on attaque celle qui fait le chargement async.
2. Je n'utilise plus resp dans test_cell_rendering parce qu'en cas d'erreur lors de la soumission, la réponse contient le message d'erreur mais pas le contenu de la cellule car chargé de manière async.De la description du ticket, le seul changement dans les tests ça devrait être en début de test charger la page, vérifier que la cellule apparait bien comme devant être chargée en asynchrone, ensuite faire le chargement asynchrone, et la suite, la reprendre sans changements aux tests, vu qu'après le chargement asynchrone l'info est dans le cache et il doit y avoir bascule sur le rendu synchrone.
Vrai. Ok c'est fait dans ce patch.
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchonous-199.patch 0001-booking-calendar-make-cell-rendering-asynchonous-199.patch ajouté
Les tests dans le précédent patch n'étaient pas valides. Le fait de mocker requests.get ne permettait de valider que les données étaient en cache ou non,
Je mocke donc requests.send dans celui ci.
Mis à jour par Frédéric Péters il y a plus de 6 ans
En cours de route le message de commit est devenu "... asynchonous". Je n'imagine même pas comment.
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch ajouté
Frédéric Péters a écrit :
En cours de route le message de commit est devenu "... asynchonous". Je n'imagine même pas comment.
Message de commit corrigé.
Mis à jour par Frédéric Péters il y a plus de 6 ans
+ return all((self.agenda_reference, self.formdef_reference)) \
Je passe la main; faut trouver un jeune pour accepter ça.
Mis à jour par Serghei Mihai (congés, retour 15/05) il y a plus de 6 ans
Même pour un plus jeune c'est pas vraiment lisible.
Mis à jour par Josué Kouka il y a plus de 6 ans
- Fichier 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch 0001-booking-calendar-make-cell-rendering-asynchronous-19.patch ajouté
Bon j'ai mis un and.
Mis à jour par Josué Kouka il y a plus de 6 ans
- Statut changé de En cours à Résolu (à déployer)
- % réalisé changé de 0 à 100
commit 7b22f9fdf74b75b3ca53742cb13511a43d4a3453
Author: Josue Kouka <jkouka@entrouvert.com>
Date: Mon Nov 13 10:27:56 2017 +0100
booking calendar: make cell rendering asynchronous (#19949)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Fermé
booking calendar: make cell rendering asynchronous (#19949)