@icanbwell/baileyai-chat-ui 1.0.17 → 1.0.18
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/README.md +26 -7
- package/dist/baileyai-chat-ui.cjs +3 -3
- package/dist/baileyai-chat-ui.js +627 -615
- package/dist/index.d.ts +39 -12
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -181,6 +181,15 @@ const history = useBaileyConversations({ client }); // conversations, loadMore,
|
|
|
181
181
|
state (the partial text stays visible, `onAssistantMessageComplete` does not fire). A custom
|
|
182
182
|
transport should set `interrupted: true` in that case, and must resolve `streamChat` only when the
|
|
183
183
|
response body has closed.
|
|
184
|
+
When no response arrives (`fetch` rejects, or `getHeaders` throws) `streamChat` still resolves with
|
|
185
|
+
`status: undefined` and the fixed `errorMessage: 'Request failed'`, and now also sets `errorKind: 'network'`
|
|
186
|
+
so a host can choose its own copy. `errorCause` carries the error `fetch` threw; it is not set when
|
|
187
|
+
`getHeaders` threw (it can carry auth detail). Both fields are optional and additive, and
|
|
188
|
+
`useBaileyChat`'s copy is unchanged. A caller abort and the idle timeout still reject with the abort
|
|
189
|
+
reason (`TimeoutError` for the idle timeout), and a mid-stream drop still resolves `interrupted: true`
|
|
190
|
+
without `errorKind`. Browsers do not distinguish CORS, DNS or offline, so do not show `errorCause.message`
|
|
191
|
+
to users without review and do not log the request URL.
|
|
192
|
+
A multi-byte character cut off at the end of the stream is flushed as a final `onChunk`.
|
|
184
193
|
- Every call has a timeout (`requestTimeoutMs`, default 30s; the stream uses an idle timeout,
|
|
185
194
|
`idleTimeoutMs`). A failed best-effort cleanup is reported through `onCleanupError` and never thrown.
|
|
186
195
|
- **Nothing is logged** by the client or the hooks, and request/response bodies are never placed in
|
|
@@ -218,13 +227,23 @@ const history = useBaileyConversations({ client }); // conversations, loadMore,
|
|
|
218
227
|
(`X-Conversation-Id`) or one you seed. Without `sub` the stored id is held unvalidated; after a
|
|
219
228
|
shared-browser user switch the server rejects the foreign id and the library adopts the
|
|
220
229
|
server-reported one, so the worst case is a lost first-turn context.
|
|
221
|
-
- **Lost server context is surfaced.**
|
|
222
|
-
|
|
223
|
-
|
|
224
|
-
|
|
225
|
-
|
|
226
|
-
|
|
227
|
-
|
|
230
|
+
- **Lost server context is surfaced.** A turn that sent a held id signals context loss when the
|
|
231
|
+
server did not continue that conversation, for one of two reasons. `reason: 'id'`: it came back
|
|
232
|
+
with no id, or a different one (persistence off, an id it does not know). `reason: 'history'`: it
|
|
233
|
+
reported the same id but `conversation.history_status` on `response.created` / `response.completed`
|
|
234
|
+
(the last one the turn carries wins) is `'failed'` or `'empty'`, meaning the stored history was not
|
|
235
|
+
loaded. In both cases the hook drops the held id and its stored value, clears the paging state, sets
|
|
236
|
+
`contextLost: true` until the next turn, and calls `onContextLoss({ sentId, reportedId, reason })`
|
|
237
|
+
(the library always sets `reason`, though it is optional in the type; `reportedId` is absent when the server reported none); the next turn sends
|
|
238
|
+
the full transcript. `'loaded'`, an absent field and any unrecognised value change nothing, and a
|
|
239
|
+
first turn (no id sent) never signals loss. A host-seeded id whose turn reports `'empty'` also
|
|
240
|
+
signals loss: a seeded id is only valid for resuming a stored conversation. The backend also sends
|
|
241
|
+
`history_loaded` (number of prior messages loaded); the library does not read it, it is for host
|
|
242
|
+
diagnostics. A turn that fails outright (4xx/5xx) is reported as an error as before. Older backends
|
|
243
|
+
do not send `history_status`, so for them only `reason: 'id'` can occur and a history load that
|
|
244
|
+
fails while the server reports the same id is still not detectable. Residual risk until the backend
|
|
245
|
+
change (baileyai PR #554, language-model-common PR #136) is deployed and released: the `'history'`
|
|
246
|
+
path is inert.
|
|
228
247
|
- **Persistence off on the server.** Stable conversation ids only help where the server persists
|
|
229
248
|
conversations (the conversation routes return 503 when persistence is off). The library does not
|
|
230
249
|
probe for this: enable stable ids (pass a `client` and keep the default storage) only in environments
|