@q9labsai/chalk-react-native 5.1.0 → 5.2.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,57 @@
1
1
  # Changelog
2
2
 
3
+ ## 5.2.0
4
+
5
+ ### confirmed-call-entry
6
+
7
+ Count a person in a call only after they have fully entered it. The built-in
8
+ browser and React Native Sync clients ask Sync for entry confirmation on the Sync
9
+ URL (`entry_confirmation=1`). When Sync's `welcome` grants it, the client sends
10
+ `entered` once Sync is live and media has started, so a failed connection no
11
+ longer leaves a ghost participant or an attendance record. Against an older Sync,
12
+ the client sends the previous hello and Sync confirms entry at hello as before.
13
+
14
+ `confirmEntered()` on a custom `createSyncClient` implementation is optional.
15
+ Implementing it, and building `V1SyncClient` with `entryConfirmation: true`, adds
16
+ the confirmed entry above. Without it, the client never asks for entry
17
+ confirmation and Sync confirms the entry at hello, as in 5.0.x. `V1SyncClient`
18
+ asks only when it is built with `entryConfirmation: true`.
19
+
20
+ When entry fails, the client cancels the pending admission through the new
21
+ `cancelEpisodeParticipantJoin` endpoint (`POST .../participants/:participant_id/cancel-join`),
22
+ and a retry keeps the same person. If Sync reports `entry timeout` because the
23
+ pending seat expired before entry, the connection fails as a retryable
24
+ `sync_start_failed` instead of rejected access, and the client does not reconnect
25
+ the expired seat with the same grant.
26
+
27
+ The admission contract declares the 409 `participant.not_active` response when
28
+ a retried admission names a participant that has already left. The public
29
+ `AdmitEpisodeParticipantError` union stays compatible with 5.1.0; this response
30
+ uses the existing `HttpClientError` channel, with its code in the response body.
31
+ The dashboard reads that code and retries once with a fresh join key.
32
+
33
+ Sync assigns each entry a participant-local generation and returns it in
34
+ `welcome`. The client resumes that generation through the `entry_generation`
35
+ WebSocket query, even after refreshing its credential. Confirmation advances
36
+ ownership only forward and voids older pending Leaves. Acceptance and completion
37
+ both fence a Leave against the confirmed generation, so reattaching the same
38
+ seat cannot let the previous mount remove it. Previous Sync ignores this query.
39
+ Legacy sockets receive a server generation internally without changing their
40
+ welcome frame, and still confirm at hello. Participants created before seat
41
+ storage acquire it on their first live hello. When recovery replaces the Sync
42
+ client, it confirms the replacement entry before reporting recovery complete.
43
+ Completed startup also survives reconnecting from an older Sync to an upgraded
44
+ one. Recovery can finish while a previous entry's Leave is pending, and an
45
+ uncertain confirmation reply checks that entry's generation before acknowledging it.
46
+ A claimed Leave blocks later entry
47
+ admission until its provider work settles. An entry admitted before that claim
48
+ defers the older provider work until confirmation or its two-minute startup
49
+ lease expires, preventing old cleanup from closing the new entry's media.
50
+
51
+ Rollout: apply the database migrations first, then upgrade Sync, then the API and
52
+ this client. This client also works with an older Sync, and published 5.0.x
53
+ clients keep hello confirmation with the new Sync.
54
+
3
55
  ## 5.1.0
4
56
 
5
57
  - Bound each Sync and whiteboard WebSocket opening attempt to the existing 30-second startup allowance, or to `syncStartupTimeoutMs` when set. `syncStartupTimeoutMs` accepts 1 to 60,000 ms, and each attempt gets at least 10 seconds. The whiteboard retries a timed-out attempt through the existing reconnect backoff, and so does Sync once the call is live, such as after a drop or a return to the foreground. A first join does not retry a Sync socket that never opens: the join fails when its startup wait of `syncStartupTimeoutMs` ends, and a setting below 10 seconds ends the join before the attempt's own 10-second minimum. The client's 10-second default does not apply to React Native.
package/dist/client.js CHANGED
@@ -146,6 +146,7 @@ function createSyncClient(syncURL, input, lifecycle, webSocket, storage, dialTim
146
146
  lifecycle,
147
147
  webSocket,
148
148
  dialTimeoutMs,
149
+ entryConfirmation: true,
149
150
  ...storage ? { pendingStore: new AsyncStorageV1PendingTargetStore({ scope, storage }) } : {}
150
151
  });
151
152
  }
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@q9labsai/chalk-react-native",
3
- "version": "5.1.0",
3
+ "version": "5.2.0",
4
4
  "license": "MIT",
5
5
  "repository": {
6
6
  "type": "git",
@@ -106,9 +106,9 @@
106
106
  "registry": "https://registry.npmjs.org/"
107
107
  },
108
108
  "dependencies": {
109
- "@q9labsai/chalk-client": "^5.1.0",
110
- "@q9labsai/chalk-whiteboard": "^5.1.0",
111
- "@q9labsai/facehash": "^5.1.0",
109
+ "@q9labsai/chalk-client": "^5.2.0",
110
+ "@q9labsai/chalk-whiteboard": "^5.2.0",
111
+ "@q9labsai/facehash": "^5.2.0",
112
112
  "uqr": "^0.1.3"
113
113
  },
114
114
  "devDependencies": {
@@ -147,6 +147,7 @@ function createSyncClient(syncURL: string, input: SyncFactoryInput, lifecycle: R
147
147
  lifecycle,
148
148
  webSocket,
149
149
  dialTimeoutMs,
150
+ entryConfirmation: true,
150
151
  ...(storage ? { pendingStore: new AsyncStorageV1PendingTargetStore({ scope, storage }) } : {}),
151
152
  });
152
153
  }