@vidtreo/recorder 1.8.1 → 1.10.0

package/README.md

@@ -29,7 +29,7 @@ Recordings and native-camera uploads are written to an IndexedDB upload queue be
 - The queued upload keeps its idempotency key, so the backend returns the same video and the SDK uploads only the parts R2 has not verified yet.
 - Failed attempts are retried by the queue with exponential backoff (up to 10 attempts) on top of the per-part retries. Retries wait while the browser is offline.
 - Uploads authenticated with `apiKey` store the key with the queued item. Uploads authenticated with `getAccessToken` never persist a token: the provider is called again when the upload resumes, so the page must create the recorder (or native-camera handler) with the same `getAccessToken` after a reload.
-- Errors that cannot succeed on retry (such as `upload.insufficient-credits`) are reported immediately and are not retried.
+- An `upload.insufficient-credits` rejection does not use up the 10 attempts and never gives up: the upload stays in the queue and is retried every 5 minutes and whenever the queue starts. Each rejection is reported through `onUploadError` with the backend message, and the upload is removed once it succeeds.
 - When IndexedDB is unavailable (private browsing, blocked storage) the SDK uploads directly without persistence.
 
 Version 1.8.0 does not fall back to the legacy Worker-proxied upload endpoint. Applications that need the previous transport must remain on an earlier SDK version while the backend continues to support those clients. Custom Vidtreo backend deployments must expose initiation, part authorization, and confirmation endpoints. Managed R2 CORS must allow browser `PUT` plus the signed `Content-MD5` header and expose `ETag`.
@@ -747,7 +747,7 @@ const recorder = new VidtreoRecorder({
 
 | Code | Meaning |
 |------|---------|
-| `upload.insufficient-credits` | The backend rejected the upload with HTTP 402 because the account has no credits left. The upload is not retried. |
+| `upload.insufficient-credits` | The backend rejected the upload with HTTP 402 because the account has no credits left. The upload stays queued and is retried every 5 minutes (and when the queue starts), and `onUploadError` receives this error on every rejected attempt. Repeated rejections of the same upload carry `isRepeatedRejection: true` (check it with `isRepeatedUploadRejection(error)`); the built-in UIs use it to show their dialog only once. |
 
 `getUploadErrorCode` returns `null` for every other error (network failures, timeouts, and so on). Those errors are retried automatically before they are reported.
 
@@ -1113,7 +1113,7 @@ handler.destroy();
 ```
 
 - `startUploadQueue(callbacks?)` opens the IndexedDB queue and immediately resumes uploads left over from a previous page load (same idempotency key, only missing parts are sent). Its callbacks receive events for those resumed uploads and for queue-level errors. It resolves to `false` when persistent storage is unavailable; uploads then go directly to the backend.
-- `processAndUpload(onTranscodeProgress, onUploadProgress, onUploadProgressDetails?, onUploadRetry?)` queues the transcoded file and resolves with a `NativeCameraUploadResult` (`RecordingUploadResult & { blob: Blob }`) once the upload is confirmed. It rejects only with a terminal error, after the queue has exhausted its retries or immediately for `upload.insufficient-credits`. Events for this upload go to the per-call callbacks, not to the `startUploadQueue` callbacks.
+- `processAndUpload(onTranscodeProgress, onUploadProgress, onUploadProgressDetails?, onUploadRetry?)` queues the transcoded file and resolves with a `NativeCameraUploadResult` (`RecordingUploadResult & { blob: Blob }`) once the upload is confirmed. It rejects only with a terminal error, after the queue has exhausted its retries, or with `upload.insufficient-credits` on the first credit rejection; that upload stays queued and keeps retrying, and later rejections and the final success reach the `startUploadQueue` callbacks, so call `startUploadQueue` (with those callbacks) if you want to receive them. Events for this upload go to the per-call callbacks, not to the `startUploadQueue` callbacks.
 - Calling `processAndUpload` without `startUploadQueue` opens the queue on demand.
 - `destroy()` stops the queue timers. An upload that is still pending stays in IndexedDB and resumes the next time a handler or recorder starts the queue.