@voxevolv/client 0.3.14 → 0.3.15

package/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 All notable changes to `@voxevolv/client` are recorded here.
 
+## 0.3.15 - 2026-10-07
+
+- Extend initial startup to a three-minute overall deadline, with 15/20/140-second
+  readiness budgets and a backend registration budget of up to 175 seconds.
+  The final initial handshake also uses the longer budget so an absent worker
+  does not exhaust all attempts at the old 30-second hello limit. Rejoins
+  preserve the same session and deadline; cancellation and terminal
+  failures still stop immediately.
+- Deploy the accompanying backend first: it accepts up to 180 seconds and keeps
+  redispatching within the deadline instead of exhausting after three replacements.
+  Upgrade candidate applications' browser bundles to enable the longer window.
+
 ## 0.3.14 - 2026-10-06
 
 - Cancel expired context commands and uploads while they wait for reliable

package/README.md

@@ -33,7 +33,7 @@ Browsers without a build step can use the versioned bundle after publication:
 ```html
 <script type="module">
   import { RealtimeSession } from
-    "https://cdn.jsdelivr.net/npm/@voxevolv/client@0.3.6/dist/browser/index.js";
+    "https://cdn.jsdelivr.net/npm/@voxevolv/client@0.3.15/dist/browser/index.js";
 </script>
 ```
 
@@ -134,30 +134,40 @@ await session.connect({ waitForRemoteAudio: false });
 
 ## Initial connection retries
 
+Deploy the backend accepting 180-second startup registration before upgrading
+to SDK 0.3.15. Older backends reject the expanded budget. Update the candidate
+application's SDK bundle and remove shorter application-owned startup timers.
+Use the existing setup screen to show connecting progress, a longer-wait message
+after 15 seconds, and a three-minute maximum after 60 seconds. Clear UI timers
+on success, failure, or cancellation; only readiness means connected.
+
 Startup retries have been enabled by default since SDK 0.3.6 for both `new RealtimeSession()`
 and `RealtimeSession.create()`. Omit `startupRetry` or pass `true` to retry a
 session that has not connected successfully yet. The default policy allows up to
-three total attempts with 15, 20, and 50-second readiness budgets, waits one second
+three total attempts with 15, 20, and 140-second readiness budgets, waits one second
 before attempt two and three seconds before attempt three, and enforces a
-90-second overall deadline in SDK 0.3.8. The overall deadline also includes room
+180-second overall deadline in SDK 0.3.15. The overall deadline also includes room
 connection, token renewal, microphone
-publication, the client hello, and remote-audio readiness.
+publication, the client hello, and remote-audio readiness. During initial
+startup, the hello acknowledgement may wait for the longer attempt budget
+(140 seconds on the final default attempt), still bounded by the overall
+deadline. Established-session recovery retains its 30-second hello timeout.
 
-SDK 0.3.8 coordinates initial agent recovery through the session-scoped
+The SDK coordinates initial agent recovery through the session-scoped
 `POST /sessions/{id}/startup` endpoint. Registration is included in the overall
 startup deadline. It reserves 10% of the remaining budget, capped at five seconds,
-and gives the backend at most 85 seconds.
-The request limit is the smaller of that reserve and three seconds; a five-second
+and gives the backend at most 175 seconds.
+The request limit is that reserve; a five-second
 custom startup budget therefore retains about 4.5 seconds on the server.
 Repeated registrations and room-token requests never renew the backend deadline.
 Applications proxying the API must forward this route as well.
 
 The backend inspects stalled startup after ten seconds of candidate presence.
-A failed or expired dispatch can be replaced at most three times, with at least
-ten seconds between attempts. A pending/running dispatch gets a twenty-second
-startup allowance; a recent heartbeat or existing agent prevents replacement.
-The longer window gives three replacements more time to fit; scheduling and
-network delays can still reduce the number of attempts.
+A failed or expired dispatch can be replaced while the registered deadline
+has at least ten seconds remaining, with at least ten seconds between attempts.
+A pending/running dispatch gets a twenty-second startup allowance; a recent heartbeat or existing agent prevents replacement.
+The fixed deadline bounds recovery instead of an attempt-count limit, so an
+autoscaled worker can accept a later replacement.
 The server also enrolls older SDK clients at session creation and discovers their
 first candidate join through LiveKit polling, without requiring webhooks. Older
 clients retain a 65-second fallback window to match their browser deadline;
@@ -203,9 +213,9 @@ startupRetry: {
   attempts: [
     { readyTimeoutMs: 15_000 },
     { delayBeforeMs: 1_000, readyTimeoutMs: 20_000 },
-    { delayBeforeMs: 3_000, readyTimeoutMs: 50_000 },
+    { delayBeforeMs: 3_000, readyTimeoutMs: 140_000 },
   ],
-  timeoutMs: 90_000,
+  timeoutMs: 180_000,
 }
 ```