Je me retrouve face à un problème déjà éprouvé chez nous (Renault) mais qui n’a jamais trouvé de véritable solution, à savoir une erreur 400 à la suite d’un appel Rest sur API mappée (mapping spécifique Renault) mais qui possède tout de même un body (les champs de la ressource insérée) et qui effectue bien l’insert en base (ressource disponible après l’appel dans le business object).
J’ai pu expérimenter ce comportement aujourd’hui et trouver l’enchaînement d’actions menant à lui.
Etape 1 : insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans un objet. Disons, pour faire simple que cet objet n’a qu’une seule clé fonctionnelle. -> Http : 200 | insert en base OK (c’est normal)
Etape 2 : insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec la même valeur de clé fonctionnelle. -> Http : 400 | insert NOK la clé existe déjà en base (c’est normal)
Etape 3 ATTENDUE: insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec une valeur de clé fonctionnelle différente. -> Http : 200 | insert OK la clé n’existe pas en base, elle est créée (ce serait anormal).
Etape 3 OBTENUE: insert via un Post (avec Postman par exemple) ou via un formulaire Simplicite d’une ressource dans le même objet avec une valeur de clé fonctionnelle différente. -> Http : 400 | insert OK la clé n’existe pas en base mais on garde le code 400 (c’est anormal).
Je précise que pour revenir à un comportement dit normal, pas d’autre solution que le clearCache.
Pourquoi ce serait anormal ? si vous essayez de créer un record avec un clé fonctionnelle qui n’existe pas, il n’y a pas d’erreur, le record est créé c’est normal…
Bon sinon ce que je comprends de votre description c’est que quand vous vous servez des formulaires de la UI Simplicité ça fait ce qu’il faut. Mais que quand vous vous servez d’un appel POST (création) sur l’API mappée de votre objet vous obtenez un code HTTP 400 (alors que le record a quand même bien été créé) ? C’est ça ?
Pourquoi ce serait anormal ? si vous essayez de créer un record avec un clé fonctionnelle qui n’existe pas, il n’y a pas d’erreur, le record est créé c’est normal…
Effectivement ce cas est “normal”, erreur de copié collé
En revanche le fait pour l’erreur 400, le comportement est un peu délicat à décrire puisque je n’obtiens rien des logs.
→ Via les API mappées, à partir du moment où j’ai obtenu sur un appel un retour 400 pour cause de clé fonctionnelle déjà existante, tous les appels suivants tombent en 400 même si le comportement du système est celui d’un code 200 (tous les champs sont valides, insert en base correct…)
→ Via les formulaires Simplicité, il ne semble pas y avoir de problème (même si, encore une fois, je ne suis pas en mesure de dire si une erreur s’est produite puisqu’il n’y a pas de logs)
Bon je vais essayer de reproduire ce cas, je pense avoir compris le mode opératoire (le pb ne se produit que si on a obtenu un 400 lors d’un appel précédent).
C’est corrigé, il y avait effectivement un pb de reset du dernier code erreur.
Ca a été poussé sur toutes les branches actives et leurs images Docker respectives.
Merci beaucoup David pour ta réactivité.
Toutes les instances de référentiels n’ayant pas commencé l’upgrade en P24, est-il envisageable de backporter le correctif en P23 ? (j’ai bien noté le nouveau tag simplicite/platform:4.0.P23)
à ce sujet, nous avons un gros doute sur le processus d’upgrade en configuration load-balanced: en effet, nos instances de production sur AWS sont par défaut configurées en load-balancing sur 3 tâches et les build incluent le paramètre auto-upgrade=true. Dans cette configuration, que se passera-t-il lors du démarrage des 3 instances en parallèle ? L’auto-upgrade va-t-il être exécuté sur chaque instance (avec une seule et même base de données en face) ?
Non, on ne peut plus toucher à la P23, nos processus de dev et de packaging ne sont pas prévu pour ça.
L’image Docker P23 n’est conservée que pour des raisons historiques (typiquement pour pouvoir tester les upgrades). Tu auras noté qu’elle n’a plus été upgradée depuis la release de la P24.
Il est de toute façon temps de passer en P24.
Par contre la question sur l’autoupgrade en contexte multi-noeud est effectivement pertinente, ce qu’on fait d’habitude dans ce cas c’est de ne démarrer avec un noeud unique pour l’upgrade puis redémarrer avec N noeuds. Il manque donc un mode “lock” où on pourrait effectivement démarrer directement les N noeuds et le 1er qui démarrerait l’autoupgrade prendrait la main (à la manière de ce qui se passe pour la crontab) les autres noeuds attendant que ça se termine pour finir de démarrer.
Suite à un upgrade vers la P24 sur une instance load-balanced sur 3 noeuds, ma bdd a été corrompue…
J’ai réduit à 1 noeud le load-balanceur.
J’ai demandé une nouvelle bdd vierge sur laquelle j’ai redéployé mais l’interface me semble étrange :
Je ne vois plus l’entrée “User” par exemple… savez-vous si cela est normal?
Puis-je récupérer ces entrées de menu ou dois-je retenter une installation from scratch?
Mon point c’est que si plusieurs noeuds travaillent en autoupgrade en // il y a des clearcache concurrents qui se vont se déclencher avec, forcément, des résultats imprévisibles sur le cache.
Je pense qu’en redémarrant ces “corruptions” devraient disparaitre car ce sont sans doute que des “corruptions” du cache monté en mémoire, pas de la base.
Bonjour David,
ok pour la P23 (on priorise les upgrades de notré côté selon les cas).
la logique du lock nous semble plus sûre même si nous pouvons nous assurer de redéployer sur un seul noeud tout nouveau build de nouvelle release
Bruno
