# Erreur persistante lors de l'insert d'une donnée

**URL:** <https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169>\
**Category:** Defect\
**Tags:** v4-0\
**Created:** [February 18, 2020, 3:11pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169 "2020-02-18T15:11:57Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 18, 2020, 3:11pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/1 "2020-02-18T15:11:57Z")

</div>

Bonjour,

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.

Avez-vous connaissance de ce problème?

Merci

PS : le health de mon instance :

[Platform]  
Status=OK  
Version=4.0.P24  
BuiltOn=2020-01-21 00:44 (revision 120e5c70932b8d0317b8b6c80a743db7662de7f4)  
Encoding=UTF-8  
EndpointIP=172.17.0.5  
EndpointURL=http://f9abf5c13c8a:8080  
TimeZone=Europe/Paris  
SystemDate=2020-02-18 16:11:09

[Application]  
ApplicationVersion=0.8 dev  
ContextPath=  
ContextURL=https://int.rff.dev.aws.renault.com  
ActiveSessions=3  
TotalUsers=11  
EnabledUsers=7  
LastLoginDate=2020-01-21 13:35:58

[Server]  
ServerInfo=Apache Tomcat/9.0.30  
ServerType=WEB  
User=root

[OS]  
Name=Linux  
Architecture=amd64  
Version=4.14.158-101.185.amzn1.x86\_64  
SystemEncoding=UTF-8

[Disk]  
DiskFree=9149  
DiskUsable=8621  
DiskTotal=10015

[JavaVM]  
Version=13.0.1  
Vendor=N/A  
VMName=OpenJDK 64-Bit Server VM  
VMVersion=13.0.1+9  
ScriptEngine=rhino  
ScriptEngineVersion=Rhino 1.7.11 2019 05 30  
HeapFree=178757  
HeapSize=506948  
HeapMaxSize=1773888  
TotalFreeSize=1445697

[Cache]  
GrantCache=20  
GrantCacheMax=0  
GrantCacheRatio=0  
ObjectCache=285  
ObjectCacheMax=10000  
ObjectCacheRatio=2  
ProcessCache=1  
ProcessCacheMax=10000  
ProcessCacheRatio=0

[Database]  
Vendor=3  
ProductName=PostgreSQL  
ProductVersion=10.6  
DriverName=PostgreSQL JDBC Driver  
DriverVersion=42.2.9  
DBDate=2020-02-18 16:11:09  
DBDateOffset=0  
DBPatchLevel=P24;120e5c70932b8d0317b8b6c80a743db7662de7f4  
UsingBLOBs=true

[Healthcheck]  
Date=2020-02-18 16:11:09  
ElapsedTime=73

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 18, 2020, 3:20pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/2 "2020-02-18T15:20:22Z")

</div>

> [@ThomasB](#):
>
> 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).

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 ?

---

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 18, 2020, 3:42pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/3 "2020-02-18T15:42:28Z")

</div>

> 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)

Ce problème n’est pas simple à décrire…

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 18, 2020, 3:53pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/4 "2020-02-18T15:53:19Z")

</div>

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).

Je vous tiens au courant

---

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 18, 2020, 3:54pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/5 "2020-02-18T15:54:33Z")

</div>

C’est bien ça.  
Merci.

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 19, 2020, 1:17pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/6 "2020-02-19T13:17:40Z")

</div>

Ok je reproduis bien le pb décrit avec le mode opératoire indiqué.

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 19, 2020, 4:52pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/7 "2020-02-19T16:52:47Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![bmo](https://community.simplicite.io/letter_avatar_proxy/v4/letter/b/9de0a6/32.png) [@bmo](https://community.simplicite.io/u/bmo)\
**Post date:** [February 19, 2020, 6:37pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/8 "2020-02-19T18:37:50Z")

</div>

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) ?

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 20, 2020, 7:58am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/9 "2020-02-20T07:58:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 20, 2020, 8:53am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/10 "2020-02-20T08:53:33Z")

</div>

Bonjour,

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 :

 ![image](https://community.simplicite.io/uploads/default/original/2X/7/7b6e40e08adbebc89649fbc5d23d80d23bff55a8.png)

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?

Le health :

[Platform]  
Status=OK  
Version=4.0.P24  
BuiltOn=2020-02-19 18:56 (revision 154407ecda5b5207d9d265e80b8256320fcc0ffd)  
Encoding=UTF-8  
EndpointIP=172.17.0.12  
EndpointURL=[http://49f20f05ca27:8080](http://49f20f05ca27:8080)  
TimeZone=Europe/Paris  
SystemDate=2020-02-20 09:50:31

[Application]  
ApplicationVersion=4.0  
ContextPath=  
ContextURL=[https://ope.rff.ope.aws.renault.com](https://ope.rff.ope.aws.renault.com)  
ActiveSessions=1  
TotalUsers=3  
EnabledUsers=2  
LastLoginDate=

[Server]  
ServerInfo=Apache Tomcat/9.0.31  
ServerType=WEB  
User=root

[OS]  
Name=Linux  
Architecture=amd64  
Version=4.14.158-101.185.amzn1.x86\_64  
SystemEncoding=UTF-8

[Disk]  
DiskFree=9148  
DiskUsable=8620  
DiskTotal=10015

[JavaVM]  
Version=13.0.2  
Vendor=N/A  
VMName=OpenJDK 64-Bit Server VM  
VMVersion=13.0.2+8  
ScriptEngine=rhino  
ScriptEngineVersion=Rhino 1.7.11 2019 05 30  
HeapFree=290518  
HeapSize=506944  
HeapMaxSize=1773888  
TotalFreeSize=1557462

[Cache]  
GrantCache=7  
GrantCacheMax=0  
GrantCacheRatio=0  
ObjectCache=270  
ObjectCacheMax=10000  
ObjectCacheRatio=2  
ProcessCache=1  
ProcessCacheMax=10000  
ProcessCacheRatio=0

[Database]  
Vendor=3  
ProductName=PostgreSQL  
ProductVersion=10.6  
DriverName=PostgreSQL JDBC Driver  
DriverVersion=42.2.10  
DBDate=2020-02-20 09:50:31  
DBDateOffset=0  
DBPatchLevel=P24;154407ecda5b5207d9d265e80b8256320fcc0ffd  
UsingBLOBs=true

[Healthcheck]  
Date=2020-02-20 09:50:31  
ElapsedTime=8

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 20, 2020, 9:10am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/11 "2020-02-20T09:10:59Z")

</div>

Il faut changer de scope pour se mettre en “Simplicite administrator”  
Out of the box on est sur le scope “Application design” qui est plus restreint

 ![image](https://community.simplicite.io/uploads/default/original/2X/0/0e23c51b178b6e0f156ab48544ffe992775b856e.png)

---

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 20, 2020, 9:12am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/12 "2020-02-20T09:12:33Z")

</div>

Ah d’accord! Merci !

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 20, 2020, 9:16am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/13 "2020-02-20T09:16:38Z")

</div>

Par contre la “corruption” de la base je ne pense pas, au pire les instances ont fait des choses en concurrence et sont dans un état foireux.

Comme je l’ait dit, il aurait fallu démarrer une fois mono noeud, arrêter et redémarrer multi noeuds.

---

<div class="post-metadata">

**Author:** ![ThomasB](https://community.simplicite.io/letter_avatar_proxy/v4/letter/t/f07891/32.png) [@ThomasB](https://community.simplicite.io/u/ThomasB)\
**Post date:** [February 20, 2020, 9:28am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/14 "2020-02-20T09:28:14Z")

</div>

Par corrompue, je vux dire que certains objets avaient disparu de la bdd, notamment l’objet “import utilisateur”

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 20, 2020, 10:17am UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/15 "2020-02-20T10:17:13Z")

</div>

Y compris après un arret-relance ?

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.

---

<div class="post-metadata">

**Author:** ![bmo](https://community.simplicite.io/letter_avatar_proxy/v4/letter/b/9de0a6/32.png) [@bmo](https://community.simplicite.io/u/bmo)\
**Post date:** [February 20, 2020, 12:21pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/16 "2020-02-20T12:21:48Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![david](https://community.simplicite.io/user_avatar/community.simplicite.io/david/32/5703_2.png) [@david](https://community.simplicite.io/u/david)\
**Post date:** [February 20, 2020, 12:26pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/17 "2020-02-20T12:26:34Z")

</div>

Oui je vous tiens au courant pour la mise en place du lock sur l’autoupgrade.

Le pb avec les locks c’est la stratégie d’unlock en cas de pb…

---

<div class="post-metadata">

**Author:** ![scampano](https://community.simplicite.io/user_avatar/community.simplicite.io/scampano/32/10010_2.png) [@scampano](https://community.simplicite.io/u/scampano)\
**Post date:** [March 23, 2022, 12:21pm UTC](https://community.simplicite.io/t/erreur-persistante-lors-de-linsert-dune-donnee/2169/18 "2022-03-23T12:21:15Z")

</div>

Closed on March 23, 2022, 12:21pm UTC