Skip to content

Enhance: differentiate CNAV's unattributed provider error from the generic baseline - #322

Closed
Samuelfaure wants to merge 2 commits into
developfrom
enhance/cnav_404_is_502_bis
Closed

Enhance: differentiate CNAV's unattributed provider error from the generic baseline#322
Samuelfaure wants to merge 2 commits into
developfrom
enhance/cnav_404_is_502_bis

Conversation

@Samuelfaure

@Samuelfaure Samuelfaure commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #321 (return ProviderUnknownError instead of 404 for unattributed CNAV errors), addressing feedback that the new error was indistinguishable from the existing generic ProviderUnknownError example in the swagger docs.

The CNAV-specific unattributed 404 and the generic ProviderUnknownError
baseline both surfaced as code 37999 with an identical title, making
them indistinguishable in the API docs. Make ProviderUnknownError's
subcode overridable per instance (default stays '999', so the ~50
other unknown_provider_response! call sites are unaffected), add
subcode 998 "Réponse inconnue du fournisseur de données" to the error
catalog, and have CNAV's fallback use it.
Run siade/bin/generate_swagger.sh to reflect the previous commit:
the CNAV-specific unattributed-error example now shows code 37998
"Réponse inconnue du fournisseur de données" instead of duplicating
the generic 37999 baseline example.
@Samuelfaure
Samuelfaure requested review from Un3x and skelz0r August 6, 2026 13:26
@skelz0r

skelz0r commented Aug 6, 2026

Copy link
Copy Markdown
Member

Je ne comprends pas pourquoi.. la 404 "inconnue" est connue ..? Est-ce qu'on peut avoir des payloads d'exemple ?

@Samuelfaure

Samuelfaure commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

la 404 "inconnue" est connue ..?

Non, je sais pas pourquoi tu dit ça 🤔

@skelz0r

skelz0r commented Aug 7, 2026

Copy link
Copy Markdown
Member

Du coup je ne comprends pas cette PR. Le but de renvoyer des unknown payloads est que l'on qualifie les erreurs au fur et à mesure. Si la 404 "inconnue" est une payload fixe celle ci est connue et doit être renvoyée comme une 404. Si celle ci n'est pas connue on la qualifie dans une 404 et on garde notre erreur inconnue pour les cas non connus.

@skelz0r

skelz0r commented Aug 7, 2026

Copy link
Copy Markdown
Member

Et l'assertion pour moi est fausse: il n'y a pas de disjonction à faire sur les erreurs inconnues car c'est inconnu 🤔

@Samuelfaure

Copy link
Copy Markdown
Contributor Author

Ok je ferme du coup

@Samuelfaure Samuelfaure closed this Aug 7, 2026
@skelz0r

skelz0r commented Aug 8, 2026

Copy link
Copy Markdown
Member

Mais du coup j'aimerais bien que l'on clarifie quand même un point : les 404 qu'on qualifie en "inconnue" ici sont vraiment des inconnues métier pour nous, du genre 1. le FD renvoi un code/message qu'on ne connait pas, ou c'est 2. une raison que nous on connaît qui est "inconnue" pour le FD (avec un code/message fixe) ?

Si c'est 1 on n'a rien à faire, si c'est 2 faut traiter comme une 404 normale (limite on le track à part pour le remonter au FD si il en a besoin) parce qu'en vrai c'est une notion métier connue de nous du coup.

cc @Un3x

@Samuelfaure

Copy link
Copy Markdown
Contributor Author

De ce que j'ai compris c'est clairement 1. ; je laisse @Un3x me corriger au besoin

@skelz0r

skelz0r commented Aug 10, 2026

Copy link
Copy Markdown
Member

Dans ce cas là à chaque cas inconnu faut analyser la réponse, qualifier et coder la gestion. Le but étant de ne plus avoir de cas inconnu qui remonte.

@Samuelfaure

Copy link
Copy Markdown
Contributor Author

Oui, c'est le plan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants