Project

General

Profile

Development #60817

wscalls: pouvoir n'enregistrer que les erreurs "techniques" (et éviter "[wscalls] 200 Ok")

Added by Benjamin Dauvergne about 1 year ago. Updated about 1 year ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
19 January 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Cf. ticket remontant le dérangement dans #60814

Les drapeaux "notify_on_errors" et "record_on_errors" mélange erreurs techniques (exceptions, code HTTP >= 400) et erreurs logiques data['err'] != 0. Et dans ce dernier cas l'erreur a un intitulé absolument pas clair de [WSCALLS] 200 Ok. Je pense qu'il serait judicieux soit de ne rien faire sur du non zéro, soit de séparer ce cas das un autre paramétrage et d'avoir un intitulé plus clair [WSCALLS] aplication error "<err_desc or err>" (si err != 1).


Related issues

Related to w.c.s. - Development #61953: wscall: logger le nom du wscall dans l'erreurNouveau18 February 2022

Actions

History

#2

Updated by Benjamin Dauvergne about 1 year ago

  • Subject changed from wscalls: pouvoir n'enregistrer que les erreurs "techniques" to wscalls: pouvoir n'enregistrer que les erreurs "techniques" (et éviter "[wscalls] 200 Ok")
#3

Updated by Marie Kuntz (absente) about 1 year ago

Assez d'accord pour séparer les 2, jusqu'ici je n'avais pas compris que les "erreurs" sur code 200 correpsondaient à err != 0, on en apprend tous les jours

#4

Updated by Thomas Noël about 1 year ago

Je vote pour parvenir à enregistrer « [WSCALLS] aplication error "<err_desc or err>" » en cas de retour d'erreur logicielle (err != 0). Juste pour garder un peu de cohérence sur la notion d'erreur, on présente ces erreurs comme telles, alors enregistrons-les avec "notify_on_errors" et "record_on_errors"

A priori ça se joue dans wcs/wscalls.py ici:

    if (app_error_code != 0 or status >= 400) and (notify_on_errors or record_on_errors):
        summary = '<no response>'
        if response is not None:
            summary = '%s %s' % (status, response.reason)
        get_publisher().record_error(
            summary, context='[WSCALL]', notify=notify_on_errors, record=record_on_errors
        )

et dans wcs/wf/wscall.py :

            if exception is None:
                summary = '<no response>'
                if response is not None:
                    summary = '%s %s' % (response.status_code, response.reason)
            else:
                exc_type, exc_value = sys.exc_info()[:2]
                summary = traceback.format_exception_only(exc_type, exc_value)[-1]

            get_publisher().record_error(
                error_summary=summary,

Dans les deux cas il faudrait ajouter l'info sur err (et err_desc + err_class s'ils sont là) en plus de juste « '%s %s' % (response.status_code, response.reason) »

#5

Updated by Benjamin Dauvergne about 1 year ago

Du ticket lié je devine aussi un autre problème, c'est que le tech_id qui permet de regrouper les erreurs est construit à partir du résumé qui se résume malheureusement à formdef_id + '200 Ok'. Si ce webservice.xyz est utilisé dans plusieurs conditions de diverses manières, ça ne fait qu'une erreur et on a jamais le contexte du champ concerné, ni d'ailleurs le nom du webservice.

Il faudrait ajouter à record_error la possibilié de désigner le web-service, ainsi que le champ (mais le champ on devrait récupérer ça du contexte poser lors de l'évaluation de la condition d'une manière ou d'une autre).

#6

Updated by Benjamin Dauvergne 11 months ago

Also available in: Atom PDF