Délais d'attente
Ce qui se passe quand une requête dure : les bornes que le serveur s'impose, ce que vous recevez quand elles sont atteintes, et comment reprendre après un délai dépassé côté client.
Noryo ne publie aucun engagement de latence. Aucune valeur n'est promise tant qu'elle n'a pas été mesurée sur du trafic réel. Choisissez vos délais côté client en fonction de vos propres contraintes, et prévoyez qu'une requête puisse expirer de votre côté.
Les bornes côté serveur
Le serveur ne laisse aucune étape attendre indéfiniment. Chaque borne atteinte produit une réponse précise, et aucune ne facture :
| Étape | Si elle dépasse sa borne | Facturé ? | Mémorisé ? |
|---|---|---|---|
| Moteur de résolution | 503 engine_error | non | non |
Attente d'une requête identique en cours (même Idempotency-Key) | 503 busy, avec Retry-After | non | non |
| Contention au moment du règlement | 503 busy, avec Retry-After | non | non |
| Règlement | 500 internal_error | voir ci-dessous | voir ci-dessous |
Les valeurs de ces bornes sont des réglages internes, ajustables sans changer le contrat : elles ne sont pas publiées et ne doivent pas servir à dimensionner vos délais.
Le cas du 500
Un 500 signifie que Noryo n'a pas pu confirmer l'issue de la tentative. Le règlement étant atomique (clé d'idempotence, facturation et réponse écrites ensemble), deux cas seulement sont possibles :
- la tentative n'a pas été réglée : rien n'existe, et une reprise la traite comme une première requête ;
- la tentative a été réglée : sa réponse est mémorisée, et une reprise avec la même
Idempotency-Keyla rend, avecNoryo-Idempotency-Replayed: true.
Dans les deux cas, reprendre avec la même clé donne la bonne réponse et ne facture qu'une fois.
Après un délai dépassé côté client
Si votre client abandonne une requête avant la réponse, vous ne savez pas si elle a été réglée. Ne devinez pas : reprenez.
| Ce que la requête portait | Reprise | Résultat |
|---|---|---|
Idempotency-Key | Même clé, même corps | Réponse mémorisée si la première a abouti, sinon traitement normal. Si la première est encore en cours, la reprise l'attend, ou rend 503 busy. |
external_transaction_id seul | Même corps | Si la première a abouti : son résultat, deduplicated: true, non facturé. Sinon : traitement normal. |
| Les deux | Même clé, même corps | Les deux protections s'appliquent. |
Une création sans aucun des deux identifiants est refusée d'emblée (400 identifier_required) : il n'existe pas de cas où une reprise après un délai dépassé puisse facturer deux fois.
Choisir un délai côté client
- Fixez un délai par requête et un nombre maximal de tentatives, plutôt qu'un délai global infini.
- Gardez la même
Idempotency-Keypour toutes les tentatives d'une opération. - Mesurez vos propres latences et journalisez le
Noryo-Request-Idde chaque tentative : en cas de lenteur anormale, c'est ce qui permet au support de retrouver la tentative exacte.
Une boucle complète est donnée dans Reprises.
Publié le 2026-10-08 21:04 UTC (version 1).