Skip to main content
La version 4.0.0 modifie la manière dont le SDK réessaie, afin qu’il ne répète que ce qui peut l’être sans risque. Aucune méthode, option ni export n’a été renommé ou supprimé.

​
Prérequis

Inchangés : Node.js 20 ou plus récent, ou un navigateur ; ESM et CommonJS.

​
Résumé des changements incompatibles

​
429 n’est plus réessayé

RATE_LIMITED couvre à la fois une fenêtre par route et un blocage du compte ou de l’IP qui peut durer environ 30 minutes : le SDK ne le réessaie donc plus. Cela inclut la limite des envois simples et TOO_MANY_CONCURRENT_UPLOADS. Gérez-le vous-même, et attendez avant de réessayer :
La seule exception est TOO_MANY_CONCURRENT_CHUNKS sur une partie multipart : le serveur refuse la partie avant de la lire, le SDK la renvoie donc dans la limite de maxRetries.

​
Les écritures ont droit à une seule tentative

Les erreurs réseau et les 5xx ne sont désormais réessayés que sur les appels GET et sur les parties d’un envoi multipart. Ces appels ont droit à une seule tentative :
  • put() simple, ainsi que le démarrage, la finalisation et l’annulation d’un envoi multipart ;
  • update(), copy(), move(), delete() ;
  • rules.set(), uploadTokens.create(), shares.create(), shares.revoke().
Ne réessayez vous-même une écriture que lorsque la répéter est sans risque pour vous, par exemple un put() vers le même nom avec overwrite: true. Voir Réessayer vous-même les écritures.

​
Moins de nouvelles tentatives, backoff plus court

maxRetries vaut désormais 2 par défaut (contre 5 auparavant), et le backoff est plafonné à 8 secondes (contre 30). Pour conserver l’ancien budget sur les lectures et les parties multipart :
Cela ne rétablit pas les nouvelles tentatives sur 429 ni sur les écritures.

​
SavedRule.active_from est optionnel

L’API n’envoie active_from que pour les règles avec delete_after_days. En TypeScript, gérez undefined :

​
delete([id]) avec un seul identifiant

Un lot contenant un seul identifiant signale désormais PREFIX_NOT_ALLOWED dans failed, comme n’importe quel autre lot, au lieu de lever une erreur :
delete(id) avec une simple chaîne lève toujours une erreur.

​
RATE_LIMIT est déprécié

Le service n’envoie plus RATE_LIMIT : le blocage du compte ou de l’IP est RATE_LIMITED. L’ancien code reste dans BlobErrorCode pour que les comparaisons existantes compilent toujours ; remplacez-les par RATE_LIMITED. DUPLICATE_RULE_PREFIX a été ajouté.

​
Corrections

  • Un corps de réponse tronqué en cours de lecture est désormais une erreur réseau : il est réessayé sur les appels GET et les parties multipart, et sinon l’erreur fetch d’origine est levée (auparavant, c’était UNKNOWN_ERROR).
  • Un envoi multipart échoué attend désormais les parties encore en cours avant d’annuler, de sorte qu’aucune partie n’arrive après l’annulation et qu’aucune requête ne survit à put().

​
Liste de contrôle

1

Gérez vous-même les 429

Interceptez RATE_LIMITED et temporisez ; le SDK ne le réessaie plus.
2

Passez en revue les écritures

N’ajoutez vos propres nouvelles tentatives qu’aux écritures répétables sans risque.
3

Choisissez un budget de nouvelles tentatives

Passez { maxRetries: 5 } si vous dépendiez de l’ancien nombre de tentatives sur les lectures et les parties multipart.
4

Mettez à jour les types

Gérez le cas où active_from vaut undefined, et remplacez RATE_LIMIT par RATE_LIMITED.