Attraper les erreurs de décodage du JSON, et indiquer un retry des paquets en erreur #4849

Closed
opened 1 year ago by marcimat · 5 comments
marcimat commented 1 year ago
Owner

Pour le suivi d’une proposition de g0uz pour améliorer Bigup, notamment lorsque le serveur retourne des 429 (trop de requêtes).

  • Il faut éviter aussi des erreurs de parsing du JSON si celui ci est mal formé pour diverses raisons, en les capturant et les affichant correctement,
  • Il faut indiquer un retry dans la configuration de flow.js
Pour le suivi d’une proposition de g0uz pour améliorer Bigup, notamment lorsque le serveur retourne des 429 (trop de requêtes). - Il faut éviter aussi des erreurs de parsing du JSON si celui ci est mal formé pour diverses raisons, en les capturant et les affichant correctement, - Il faut indiquer un retry dans la configuration de flow.js
g0uZ commented 1 year ago

Règle aussi l'erreur JS mentionnée ici : #4484

L'erreur HTTP rencontrée n'est pour le moment pas pris en compte/affichée. On affiche l'exception JS levée, donc l'erreur de parsing JSON mais pas plus.

(Je cherche pour voir s'il est possible d'avoir à minima le code retour HTTP & message associé)

Règle aussi l'erreur JS mentionnée ici : https://git.spip.net/spip/bigup/issues/4484 L'erreur HTTP rencontrée n'est pour le moment pas pris en compte/affichée. On affiche l'exception JS levée, donc l'erreur de parsing JSON mais pas plus. (Je cherche pour voir s'il est possible d'avoir à minima le code retour HTTP & message associé)
Poster
Owner

Bon, ça semble déjà fonctionner.
Note que je pense baisser le nombre de retry. 25 me parait bien trop.

Chez sf. il y a possibilité de mettre un coef multiplicateur de durée entre chaque tentative https://symfony.com/blog/new-in-symfony-5-2-retryable-http-client

Certains outils regardent s’il y a des header X-retry-after ou retry-after dans le retour également.

Dans flow.js, le retry est géré dans la fonction doneHandler… mais rien de personnalisable.

Bon, ça semble déjà fonctionner. Note que je pense baisser le nombre de retry. 25 me parait bien trop. Chez sf. il y a possibilité de mettre un coef multiplicateur de durée entre chaque tentative https://symfony.com/blog/new-in-symfony-5-2-retryable-http-client Certains outils regardent s’il y a des header X-retry-after ou retry-after dans le retour également. Dans flow.js, le retry est géré dans la fonction doneHandler… mais rien de personnalisable.
Poster
Owner

Bon, c’est dans master.
Je reporterai pour SPIP 4.0 (branche 2.0 sur bigup)

Bon, c’est dans master. Je reporterai pour SPIP 4.0 (branche 2.0 sur bigup)
Owner

On peut fermer non ?

On peut fermer non ?
Poster
Owner

I think so.

I think so.
marcimat closed this issue 12 months ago
b_b added the
amélioration
label 12 months ago
b_b added this to the spip-4.0 milestone 12 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.