Requisitos
Sin cambios: Node.js 20 o más reciente, o un navegador; ESM y CommonJS.Resumen de cambios incompatibles
El 429 ya no se reintenta
RATE_LIMITED cubre tanto una ventana por ruta como un bloqueo de cuenta o de IP que puede durar unos 30 minutos, así que el SDK ya no lo reintenta. Esto incluye el límite de subidas simples y TOO_MANY_CONCURRENT_UPLOADS. Gestiónalo tú mismo y espera antes de volver a intentarlo:
TOO_MANY_CONCURRENT_CHUNKS en una parte multipart: el servidor rechaza la parte antes de leerla, así que el SDK la vuelve a enviar dentro de maxRetries.
Las escrituras tienen un único intento
Los errores de red y los5xx ahora solo se reintentan en las llamadas GET y en las partes de las subidas multipart. Estas llamadas tienen un solo intento:
put()simple, y el inicio, la finalización y el aborto de una subida multipart;update(),copy(),move(),delete();rules.set(),uploadTokens.create(),shares.create(),shares.revoke().
put() al mismo nombre con overwrite: true. Consulta Reintentar escrituras por tu cuenta.
Menos reintentos, backoff más corto
maxRetries ahora vale 2 por defecto (antes 5), y el backoff tiene un máximo de 8 segundos (antes 30). Para mantener el presupuesto anterior en las lecturas y las partes multipart:
429 ni los de las escrituras.
SavedRule.active_from es opcional
La API solo envía active_from en las reglas con delete_after_days. En TypeScript, ten en cuenta el caso undefined:
delete([id]) con un solo id
Un lote con un solo id ahora indica PREFIX_NOT_ALLOWED en failed, como cualquier otro lote, en lugar de lanzar un error:
delete(id) con un string simple sigue lanzando el error.
RATE_LIMIT está obsoleto
El servicio ya no envía RATE_LIMIT: el bloqueo de cuenta o de IP es RATE_LIMITED. El código antiguo se mantiene en BlobErrorCode para que las comparaciones existentes sigan compilando; cámbialas a RATE_LIMITED. Se ha añadido DUPLICATE_RULE_PREFIX.
Correcciones
- Un cuerpo de respuesta cortado a mitad de lectura ahora es un error de red: se reintenta en las llamadas
GETy en las partes multipart, y en los demás casos se lanza el error original defetch(antes eraUNKNOWN_ERROR). - Una subida multipart fallida ahora espera a las partes que aún están en curso antes de abortar, para que ninguna parte llegue después del aborto y ninguna petición sobreviva a
put().
Lista de comprobación
1
Gestiona el 429 tú mismo
Captura
RATE_LIMITED y espera antes de reintentar; el SDK ya no lo reintenta.2
Revisa las escrituras
Añade tu propio reintento solo a las escrituras que sea seguro repetir.
3
Elige un presupuesto de reintentos
Pasa
{ maxRetries: 5 } si dependías del número anterior de intentos en las lecturas y las partes multipart.4
Actualiza los tipos
Ten en cuenta que
active_from puede ser undefined, y reemplaza RATE_LIMIT por RATE_LIMITED.