@artooi/ag-ui-web-component 0.26.0 → 0.27.0

package/CHANGELOG.md

@@ -7,6 +7,98 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.27.0] — 2026-08-26
+
+### Fixed
+
+- **A deliberate cancel was reported as an error as well as a cancellation.**
+  Pressing Stop (or Escape, or anything else that cancels a run) could put a
+  warning bubble carrying the browser's own abort text — Chrome's is
+  `BodyStreamBuffer was aborted` — directly above the muted stopped note: one
+  deliberate stop, described twice, once as a failure. Cancelling aborts the
+  response while its body is being read, and that abort can reach the AG-UI
+  subscriber as a `RUN_ERROR` event, which was forwarded to `onError` without
+  consulting the cancel flag. Only the promise route ever checked it. It looked
+  intermittent because whether the abort produces a run error depends on where
+  in the stream it lands. A cancelled run now reports the cancellation alone; a
+  run that failed on its own still reports its error.
+
+- **Chrome's mid-read abort was classified as a genuine error.**
+  `isAbortError` matched only `name === "AbortError"`, and Chrome raises
+  `TypeError: BodyStreamBuffer was aborted` when a fetch body is cancelled
+  mid-read. The cancel flag hid this in the common case; an abort arriving
+  without it — a caller aborting the request by another route — was reported as
+  a failure. A `TypeError` whose message names the abort is now read as one.
+
+- **The new-chat button deleted the conversation it left.** Pressing the header's
+  new-chat button (or the drawer's "New chat", or calling `newChat()`) cleared the
+  active thread from the store before minting the next id — the same call the
+  drawer's own delete action makes. The conversation vanished from the history
+  drawer, and with `data-threads-url` set it was deleted on the server too, since
+  the remote store answers `clear` with a `DELETE`. The line predates the history
+  drawer: it was written when "new chat" meant wiping the one conversation there
+  was, and multi-thread support was layered over it. Starting a conversation now
+  leaves the previous one where it was, to return to from the drawer. A thread
+  nothing was ever sent in is still dropped — it never appeared in the drawer, so
+  keeping it would only strand a record per press.
+
+### Added
+
+- **`ClientConversationStore.newThread()`** — start a conversation without
+  destroying one. Optional, so an existing custom store keeps working: the
+  element then mints the id itself and hands it to `setActiveThread`, which loses
+  only the store's own record that the thread is new. `SessionStorageStore` and
+  `RemoteConversationStore` both implement it.
+
+## [0.26.1] — 2026-08-25
+
+### Fixed
+
+- **A chart the server retracted stayed on screen.** When an update replaced a
+  chart with a payload that could not be drawn, the superseded chart was left in
+  place — showing numbers the server had already withdrawn, reading as current —
+  and then vanished on the next reload, because the *stored* content was the
+  version that could not be drawn. Live and reload now agree, and both say gone.
+
+- **`enableCharts()` after the element connected silently dropped every chart in
+  restored history.** History replays on connect, and charts were off at that
+  moment, so they were skipped. That is the ordinary way to call it — you have
+  to query the element to call anything on it — so the first call now redraws
+  rather than the docs asking for an ordering nobody can satisfy. The README
+  example was that order.
+
+- **A stacked chart wrote `NaN` into the DOM** for a series carrying more points
+  than there are labels. `renderChart` is exported, so it can be handed a spec
+  the validator would have refused; a cast there claimed that could not happen.
+
+- **A sparse `labels` array was accepted**, drawing a chart with blank axis
+  labels — `Array.prototype.some` skips holes.
+
+- **A spec inside the point budget could still block the main thread.** The
+  point limit bounds the data; the DOM is bounded by labels, since each emits an
+  axis node whatever the series count. Now capped at 2,000 labels, and the
+  ceiling applies again on every reload of a stored conversation.
+
+### Documentation
+
+- **Whether a pushed chart survives a reload depends on where the conversation
+  is stored**, and the README now says which is which. A client-side store keeps
+  activities; a server storing the thread as the model's message history does
+  not, because a pushed chart is deliberately not in that history. An
+  agent-requested chart survives either way — its spec travels as the tool
+  call's arguments.
+
+### Changed
+
+- **The handler/render split is now enforced by a signature rather than a
+  comment.** The replay path is handed the `render` function alone, never the
+  tool that owns it, so the code that runs on restore cannot reach `handler`.
+  The documentation claimed this guarantee was structural while the code passed
+  the whole tool around and relied on two call sites happening not to use it.
+
+- The built-in chart tool no longer builds the chart twice per call, once only
+  to choose its reply string.
+
 ## [0.26.0] — 2026-08-25
 
 ### Added
@@ -1613,7 +1705,9 @@ hosts that both arrange the page the way it expects.
 ### Notes
 - First release — exercising the automated npm OIDC publish pipeline end-to-end.
 
-[Unreleased]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.0...HEAD
+[Unreleased]: https://github.com/Artui/ag-ui-web-component/compare/v0.27.0...HEAD
+[0.27.0]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.1...v0.27.0
+[0.26.1]: https://github.com/Artui/ag-ui-web-component/compare/v0.26.0...v0.26.1
 [0.26.0]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.2...v0.26.0
 [0.25.2]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.1...v0.25.2
 [0.25.1]: https://github.com/Artui/ag-ui-web-component/compare/v0.25.0...v0.25.1

package/README.md

@@ -773,8 +773,11 @@ handler), gate `drag_and_drop` with [`confirmPredicate`](#inline-confirmation-x-
 The header carries two built-in buttons: a new-chat (✚) button and a collapse (—) toggle. The
 matching JS API:
 
-- `newChat()` — clears the transcript and the persisted history, drops the in-memory run state,
-  and mints a new thread id.
+- `newChat()` — clears the transcript, drops the in-memory run state, and mints a new thread id.
+  The conversation it leaves is **kept**: it stays in the history drawer to return to, and on a
+  server-backed store it stays on the server. Deleting one is the drawer row's own action. A chat
+  nothing was ever sent in is the exception — it was never listed, so it is dropped rather than
+  left behind.
 - `setCollapsed(collapsed)` / `toggleCollapsed()` — collapse or expand the widget. The state is
   reflected as the boolean `collapsed` attribute/property and persisted per-tab in
   `sessionStorage`, so it survives a reload.
@@ -871,6 +874,16 @@ const chat = document.querySelector("ag-ui-chat");
 chat.enableCharts(["tool", "activity"]);
 ```
 
+Order does not matter. Calling it after the element is on the page redraws any
+charts already in the restored history, so you do not have to reach the element
+before it connects — which you generally cannot.
+
+Specs are bounded, and anything outside is dropped rather than half-drawn: at
+most **20,000 points** and **2,000 labels**, and every point a finite number no
+larger than **1e15**. The first two keep a stored transcript from blocking the
+main thread on every reload; the last one keeps the value range finite, since
+scaling divides by it.
+
 **`"tool"`** registers a `render_chart` tool the agent may call. The numbers are
 in its context, so it can talk about them; it costs one model round.
 
@@ -880,6 +893,13 @@ reaches the model, there is no extra round, and this is the only route that can
 **update a chart in place** — the server repeats the same `messageId` to redraw
 it, or sends an `ACTIVITY_DELTA` to move one series as a computation advances.
 
+**Whether a pushed chart survives a reload depends on where the conversation is
+stored.** A client-side store keeps activities, so it comes back. A server that
+stores the thread as the model's message history does not — a pushed chart is
+deliberately not in that history, which is the reason to push it. A chart the
+agent asked for survives either way, because its spec travels as the tool call's
+arguments and the component redraws from those without re-running anything.
+
 Either way the payload is the same shape:
 
 ```json
@@ -917,10 +937,13 @@ chat.registerTool({
 
 **`render` is the only half a restored transcript replays.** Replaying a tool's
 *effect* is out of the question — re-running a form-filling tool on every reload
-is a bug — so the restore path holds no reference to `handler` and cannot run
-it. That makes the guarantee structural rather than a promise, and it is why
-`render` has to be a pure, deterministic function of its arguments: it runs
-again every time the conversation is restored.
+is a bug. The replay path is handed the `render` function alone, never the tool
+that owns it, so the code that runs on restore cannot reach `handler` even by
+mistake: adding a "no render? fall back to the handler" convenience there means
+changing a type signature first, which is the moment the question gets asked.
+
+That is why `render` has to be a pure, deterministic function of its arguments —
+it runs again every time the conversation is restored.
 
 ---