[Esabora] Erreur 400 sur certains dossiers

[sfinx13]

Description

Il y' a des dossiers qui n'arrivent pas dans le sas avec une réponse de type BadRequest
Investiguer sur l'état du dossier et voir la table d'historique job_event en filtrer sur les erreurs 400

Plus d'information sur
https://sentry.incubateur.net/organizations/betagouv/issues/29066/?query=is%3Aunresolved&referrer=issue-stream

[sfinx13]

Peut être des doublons

[sfinx13]

Mail envoyé à JP pour investigation @arnaudchouk

[sfinx13]

Réponse de JP

En effet, potentiellement une adresse peut être utilisée par plusieurs signalements (pas avec Histologe mais avec d'autres logiciels), donc elle n'est pas supprimée.

Quand tu renvoies tout le dossier, tu vas commencer par l'adresse en repassant le paramètre Reference_Adresse.

Et comme cette adresse est déjà répertoriée, cela va planter avec l'erreur 400 et un message du type de celui-ci-dessus.

Pour éviter cela, j'ai modifié le web service pour que tu puisses renvoyer une même adresse. Et dans ce cas l'adresse dans le sas sera mise à jour au lieu de provoquer un plantage.

J'ai fait cela sur notre base de dev, par contre cela ne sera pas mis en production avant septembre je pense.

[sfinx13]

@arnaudchouk en attente d'une nouvelle livraison coté esabora

[sfinx13]

Livraison esabora effectué en prod, observer les comportements en prod

[sfinx13]

Nous avons encore des dossiers qui nous reviennent en erreur 400 lors de l'affectation

Journal d'erreurs

https://sentry.incubateur.net/organizations/betagouv/issues/29066/?project=61&query=is%3Aunresolved&referrer=issue-stream

Journal d'evenement esabora

Esabora devrait retourner un message d'erreur spécifique mais il n'est pas stocker dans la table job_event

signalement_id	partner_id	action	created_at	status	code_status	response
29561	1951	push_dossier	2023-08-29 12:46:38	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
29561	1951	push_dossier_personne	2023-08-29 12:46:39	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
29561	1951	push_dossier_personne	2023-08-29 12:46:39	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
29561	1951	push_dossier_personne	2023-08-29 12:46:40	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
31255	811	push_dossier	2023-08-29 16:38:49	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
31255	811	push_dossier_personne	2023-08-29 16:38:53	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
31255	811	push_dossier_personne	2023-08-29 16:38:53	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for
31255	811	push_dossier_personne	2023-08-29 16:38:54	failed	400	{"message":"HTTP/1.1 400 Bad Request returned for

Signalements concernés

https://histologe.beta.gouv.fr/bo/signalements/6a8b43da-00a8-4b8a-8b40-b4a4657f499a
https://histologe.beta.gouv.fr/bo/signalements/2f6a2642-bc04-4ba9-ba6d-362e1ba29847

[hmeneuvrier]

TODO :

• rajouter des logs pour essayer de capter l'erreur envoyée par Esabora afin de comprendre d'où vient le pb
• refaire un tour sur les spécs et limitations des champs pour essayer d'identifier d'éventuels pbs restants comme était l'étage

[hmeneuvrier]

Pour le premier voir avec les spécs : https://docs.google.com/document/d/1kr714W45j3ToMxa_EPiUZxbe6qewvbOE/edit

et faire un tour sur Sentry

[hmeneuvrier]

Escalier du logement
Taille maximum : 3 caractères

faire un parseur ou tronquer la donnée escalier

[hmeneuvrier]

N° de porte du logement
Taille maximum : 30 caractères

faire un parseur ou tronquer la donnée

[hmeneuvrier]

Pour l'action push_dossier_adresse les dossiers en erreur sur les 30 derniers jours ont un champ vide pour localisationLocalisationInsee alors que les autres ont bien une donnée (13 signalements sur les 30 derniers jours dont pourtant 4 ont bien une donnée pour insee_occupant, 1 depuis la correction sur l'étage (le 18 septembre), et il n'a pas de insee_occupant)

[hmeneuvrier]

Depuis la correction sur l'étage (sortie le 18 septembre), il y a 7 job push_dossier en erreur :

• 2 sont concernés par le dépassement sur num_appart_occupant :

• 2 sont concernés par des noms de documents trop longs
  Nom de la pièce jointe
  Taille maximum : 100

Et tous contiennent "sasDossierID":null

[hmeneuvrier]

Les 16 jobs push_dossier_personne en erreur contiennent "sasDossierID":null

[hmeneuvrier]

@sfinx13 @emilschn
J'ai identifié 5 problèmes qui peuvent être à l'origine des erreurs 400 sur les dossiers Esabora (détaillés ci-dessus) :

• la donnée escalier_occupant qui doit être limitée à 3 caractères et qui parfois dépasse. Dois-je tronquer ? Parser (mais comment ?) ? Demander un agrandissement côté Esabora ?
• idem pour la donnée num_appart_occupant qui doit être limitée à 30 caractères et qui parfois dépasse
• idem pour le nom des documents limités à 100 caractères. Je tronque ou on demande un agrandissement côté Esabora ?
• et d'après les specs, normalement documentContent contient l'encodage du document en base64 et là il contient le titre du document... les spécs ont changé ?

Je pense qu'on a également un souci avec le code_insee de l'occupant, qui n'est parfois pas défini chez nous et cela semble poser un souci car le ws push_dossier_adresse est en erreur quand on envoie une chaine vide pour localisationLocalisationInsee . Alors là c'est un peu bizarre car parfois on envoie une chaine vide alors qu'on a bien la donnée insee_occupant et je ne comprend pas trop comment ça peut arriver. Mais je peux mettre en place une vérification. Si on n'a pas du tout l'insee par contre, est-ce que je mets le code postal à la place ?

Et enfin, dans les actions suivantes, push_dossier et push_dossier_personne, on a des erreurs si on a "sasDossierID":null ce qui parait assez logique, cela veut dire si je comprend bien que push_dossier_adresse a échoué, mais est-ce qu'on met en place un système de retentative ?

[hmeneuvrier]

@sfinx13 je ne trouve pas trop comment renvoyer des erreurs plus explicites dans Sentry. C'est surtout côté Esabora qu'il y a un changement à faire puisqu'on ne reçoit même pas WS_ERR_MOD_VERIFKEY (et encore moins le champ concerné), non ?

[sfinx13]

@hmeneuvrier Merci pour l'analyse

J'avais envoyé un email à JP me confirmant que les erreurs étaient bien envoyés

Mail du 25/07

Même si elle n'est pas sur sentry, techniquement on devrait récupérer l'erreur en base dans la colonne response mais c'est pas le cas :-(

Ce que je propose

• Simuler une erreur sur postman et voir la réponse et vérifier qu'on ai bien le message d'erreur
• Simuler la même erreur tout en débugguant sur Esabora AbstractEsaboraService::request

Pour envoyer des infos supplémentaire sur sentry (il faudrait que tu te mette en mode prod pour les voir)
Execution de la commande composer dump-env prod

https://docs.sentry.io/platforms/php/usage/#capturing-errors

[sfinx13]

@hmeneuvrier

Et enfin, dans les actions suivantes, push_dossier et push_dossier_personne, on a des erreurs si on a "sasDossierID":null ce qui parait assez logique, cela veut dire si je comprend bien que push_dossier_adresse a échoué, mais est-ce qu'on met en place un système de retentative ?

Si on fait une revue des limitations de champs, on aura pas besoin de faire des reprises, on devrait avoir 0 erreur 400 normalement. Parser les données conforme aux limitations reglera le problème.

Au max c'est d'avoir une commande qui permet de pousser un dossier sans devoir dire au RT de désaffecter et réaffecter après avoir corrigé le signalement.

Je te confirme si dossier_adresse est en erreur tous le reste est en 400 car on a besoin du sasDossierID

[sfinx13]

N° de porte du logement Taille maximum : 30 caractères

faire un parseur ou tronquer la donnée

Ici tronquer la donnée @hmeneuvrier

[sfinx13]

@hmeneuvrier

la donnée escalier_occupant qui doit être limitée à 3 caractères et qui parfois dépasse. Dois-je tronquer ? Parser (mais comment ?) ? Demander un agrandissement côté Esabora ?

Coté esabora ils sont assez rigide sur les limitatons, il faudra parser ici

[sfinx13]

idem pour le nom des documents limités à 100 caractères. Je tronque ou on demande un agrandissement côté Esabora ?

Tronquer

[sfinx13]

et d'après les specs, normalement documentContent contient l'encodage du document en base64 et là il contient le titre du document... les spécs ont changé ?

C'est bien encodé mais pas dans le dossier mais au moment de l'envoi
EsaboraSISHService::preparePayloadPushDossier

[sfinx13]

Je pense qu'on a également un souci avec le code_insee de l'occupant, qui n'est parfois pas défini chez nous et cela semble poser un souci car le ws push_dossier_adresse est en erreur quand on envoie une chaine vide pour localisationLocalisationInsee . Alors là c'est un peu bizarre car parfois on envoie une chaine vide alors qu'on a bien la donnée insee_occupant et je ne comprend pas trop comment ça peut arriver. Mais je peux mettre en place une vérification. Si on n'a pas du tout l'insee par contre, est-ce que je mets le code postal à la place ?

Le code insee c'est bizarre, il faut continuer à envoyer le code insee du signalement et non le code postal
@hmeneuvrier
Est ce que l'absence du code insee renvoie une erreur 400 ?

[hmeneuvrier]

TODO :

• Faire un Parser pour escalier_occupant (en regardant le format des données actuelles sur Metabase), Faire le parserTest pour tous les cas rencontrés
• Tronquer la donnée pour num_appart_occupant (mettre à jour les tests adéquats)
• Tronquer le nom des documents (mettre à jour les tests adéquats)
• Vérifier la présence du codeInsee, rappeler l'API de base adresse si besoin (mettre à jour les tests adéquats)
• Faire une commande pour ee-pousser des dossiers en erreur (à appeler à la main, notamment au moment du déploiement)
• Voir pour afficher les erreurs dans Sentry (premier message de Saidi)

[sfinx13]

Récupération des erreurs dans #1943