Autre #67478
Un PATCH sur /api/agenda/SLUG-DE-LAGENDA/event/SLUG-DE-LEVENEMENT ne retourne pas d'erreur
0%
Description
Un PATCH sur /api/agenda/SLUG-DE-LAGENDA/event/SLUG-DE-LEVENEMENT n'est pas correct car il manque le '/' final.
Mais cet appel ne retourne pas d'erreur mais les données de l'événement non modifié.
Demandes liées
Historique
Mis à jour par Valentin Deniaud il y a plus d'un an
- Assigné à mis à Mikaël Ates (de retour le 29 avril)
Pour moi il y a erreur de diagnostic, car un tel appel renvoie « 301 Moved Permanently », les API dans les autres briques qui utilisent DRF fonctionnent également comme cela.
Tu peux réessayer ou expliquer comment reproduire ? (workflow/formulaire à aller bidouiller, etc)
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a plus d'un an
- Assigné à changé de Mikaël Ates (de retour le 29 avril) à Valentin Deniaud
(Via le ticket lié.)
Action de WF de modification avec un patch : https://demarches-departement13.test.entrouvert.org/backoffice/workflows/147/status/2/items/1/
Fiche créée : https://demarches-departement13.test.entrouvert.org/backoffice/data/djs-mobilisation-team13/31/
Cela crée l'événement ici le premier événement : https://agendas-departement13.test.entrouvert.org/manage/agendas/43/events/open/
Sur cette fiche action de modification de la fiche qui fait l'appel WS Patch ci-dessus. Je change l'heure c'est ok, voir form_workflow_data_patchevent... and
https://demarches-departement13.test.entrouvert.org/backoffice/data/djs-mobilisation-team13/31/inspect
Je modifie pour l'occasion cet appel WS pour enlever le '/' final.
Fiche créée : https://demarches-departement13.test.entrouvert.org/backoffice/data/djs-mobilisation-team13/32/
Cela crée l'événement ici le second événement : https://agendas-departement13.test.entrouvert.org/manage/agendas/43/events/open/
Sur cette fiche action de modification de la fiche qui fait l'appel WS Patch ci-dessus. Je change l'heure c'est ko :
Sur https://demarches-departement13.test.entrouvert.org/backoffice/data/djs-mobilisation-team13/31/inspect
On voit que sur form_workflow_data_patchevent_time que le patch a eu lieu, et pourtant form_workflow_data_patchevent_response_data_datetime n'est pas modifié.
Peut-être que wcs gère la 302 mais que les params se perdent ?
Mis à jour par Valentin Deniaud il y a plus d'un an
Mikaël Ates a écrit :
Peut-être que wcs gère la 302 mais que les params se perdent ?
On dirait, j'ai enlevé le / à l'appel de création d'évènement et l'erreur obtenue est « Méthode "GET" non autorisée. », donc wcs aurait vu la 302 et réinterrogé en GET https://demarches-departement13.test.entrouvert.org/backoffice/data/djs-mobilisation-team13/69/inspect.
Pourtant Django n'est pas censé rediriger quand il voit un POST ou un PATCH, j'ai bien une erreur en local (et elle devrait se produire également sur le SaaS, par exemple comme dans #43662). Par contre dans les tests, pas d'erreur si j'enlève le slash et 302 à la place...
(je laisse ça là au cas où ça inspire quelqu'un mais je finirai sûrement par comprendre le pourquoi du comment)
Mis à jour par Valentin Deniaud il y a plus d'un an
- Statut changé de Nouveau à Fermé
Reproduit sur le SaaS :
10.0.0.20 - - [14/Sep/2022:14:15:09 +0200] "PATCH /api/agenda/vdeniaud/event/normal?... HTTP/1.1" 301 [0.025 s] 10.0.0.20 - - [14/Sep/2022:14:15:09 +0200] "PATCH /api/agenda/vdeniaud/event/normal/?... HTTP/1.1" 200 [0.030 s]
Chrono retourne un 301 et wcs réinterroge avec un PATCH sans les données. Alors qu'en local, on a bien une 500 levée par chrono plutôt que cette redirection.
Même mécanisme pour authentic, redirection côté SaaS, 500 en local.
C'est parti pour aller voir le code de Django et bingo,
if settings.DEBUG and request.method in ("POST", "PUT", "PATCH"):
raise RuntimeError(...)
Ça explique pourquoi j'ai quand même trouvé un ticket qui mentionnait cette trace #43662, c'est parce qu'on a désactivé le DEBUG par défaut en recette depuis.
Je ferme ici comme ça n'a rien à voir avec chrono, je vais ouvrir un ticket plus général pour en discuter.
Mis à jour par Valentin Deniaud il y a plus d'un an
- Lié à Support #69085: Sur un POST d'API, lever une erreur quand un slash final manque au lieu de rediriger ? ajouté