Produits Entr'ouvert » Passerelle

Vu aussi ce retour :

API-particulier platform "prod" returned a non 200 status 404: {'error': 'not_found', 'reason': 'Non droit. Le document ne peut être édité.', 'message': 'Non droit. Le
document ne peut être édité.'}

tu peux l'ajouter ?

Et sinon plutôt que d'exclure du logging les x messages d'erreur 404, tout exclure et ne logger que les vraies, ie le message 'no route ...' ?

Valentin Deniaud a écrit :

Et sinon plutôt que d'exclure du logging les x messages d'erreur 404, tout exclure et ne logger que les vraies, ie le message 'no route ...' ?

En creusant on trouve https://github.com/betagouv/api-caf/blob/master/lib/client/errors.json qui est la liste exhaustive des pannes pour lesquelles on ne doit rien logguer ("c'est du fonctionnel"). Je serais pour en faire une copie dans notre code, genre dans caf_errors.py, avec une fonction qui retourne une APIError quand elle reconnait un code+msg, sinon None, et utiliser ça dans le « # avoid logging ... ».

Au passage, ne pas chercher à inventer des messages en anglais qui ne serviront jamais à personne, juste envoyer le message en français.

Valentin Deniaud a écrit :

Et comme me le fait remarquer Thomas à l'oral, le code qu'on renvoie ne peut plus être 'not-found'.

Je le laisse en cas de 404, pour ne pas casser l'existant, sinon j'ajoute un laconique 'api-error'.

Allez, je vais faire mon pénible-sur-les-détails.

KNOWN_ERRORS[response.status_code] va crasher sur des erreurs autres que 400/404/500, il faut faire un « KNOWN_ERRORS.get(response.status_code, []) » ou alors plus explicitement

if response.status_code in KNOWN_ERRORS and message in KNOWN_ERRORS[response.status_code]:

Aussi, on perd quand même la partie qui gérait la présence de « data.get('error') », je trouve que quand il existe on devrait l'utiliser, renvoyer dans ce cas APIError(data.get('message', 'unknown'), data={code: data.get('error').remplace('_', '-'), etc})

Aussi, sur les APIError, garder la même structure dans tous les cas, c'est-à-dire ajouter le « 'status_code': response.status_code » comme on le fait en cas d'erreur "inconnue". (il faut toujours essayer de garder la même structure de réponse car ainsi, en cas d'appels successifs, le dernier appel par w.c.s. va bien écraser complètement toutes les données du précédent appel au niveau des données stockées dans la demande appelante). Mais bon, une fois tout ça écrit je vois que tout est un peu déjà hétéroclite dans les APIError au dessus : laisse tomber cette remarque.