chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@loquix/[email protected]

Minor Changes

• 41e85fe: Add @loquix/adapter-http, which turns an HTTP endpoint into an AgentProvider.

  AgentProvider has existed since the first release with no implementation to
  point at, so every integration started by writing streaming, cancellation and
  error handling by hand. This package covers the shape almost everyone needs: a
  POST to your own backend returning server-sent events, newline-delimited JSON, or
  plain text.

  It has no runtime dependencies and holds no credentials — the endpoint it calls
  is yours, which is what keeps provider keys on the server where they belong.

@loquix/[email protected]

Minor Changes

• a4b5156: Fix AgentController's sendTimeout cutting off long-running responses, and add streamIdleTimeout.

  Previously, sendTimeout (default 60s) was composed into the same abort
  signal that was handed to provider.send() for the entire lifetime of that
  signal. A provider that forwards the signal to fetch — which is the correct
  thing to do, and what @loquix/adapter-http does — had the timeout keep
  running after the response stream was returned, silently aborting the body.
  Any response that streamed for longer than sendTimeout in total was cut
  off mid-sentence, moved the controller to error, and was never appended to
  messages — even though the provider had already started responding
  normally.

  sendTimeout now bounds only the wait for provider.send() to resolve with
  a stream, matching its documented intent. Once that promise settles, the
  timeout is cleared and has no further effect — a stream can now run as long
  as it needs to. A negative sendTimeout (e.g. -1) no longer throws a RangeError; it is
  treated as disabled, the same as 0, and NaN falls back to the default
  rather than silently removing the guard — the same rule UploadController
  already applies to its own numeric options. (±Infinity is handled
  differently — see below.)

  To fill the gap this leaves — a server that returns headers and then goes
  quiet forever — there's a new streamIdleTimeout option (default 60_000,
  0 disables). It aborts the stream only when no chunk has arrived for that
  long, resetting on every chunk, so a long-but-healthy response is never
  punished — only actual silence is. A paused stream is exempt: pausing
  suspends idle detection for as long as it's paused.

  Because @loquix/react is linked with @loquix/core in this repo's
  changesets config, it receives the same version bump even though none of its
  own code changed.

  StreamingController.connect() takes an optional second argument carrying
  that timeout. connect() itself defaults it to 0 (disabled), so a bare
  connect(stream) — every call that existed before this option was added —
  arms no idle timer and is genuinely unaffected. AgentController is the one
  caller that opts into the 60s default described above; it resolves that
  default itself before calling connect(), so its own behavior (unlike a
  direct connect() call) does change from 0.5.0 in exactly the way the rest
  of this note describes.

  If you previously set sendTimeout: 0 to disable timeouts entirely, you
  must now also set streamIdleTimeout: 0. streamIdleTimeout is a new
  option and defaults to on (60_000), so that exact 0.5.0 opt-out
  configuration no longer means "no timeouts" — it now arms a 60-second idle
  timer against the response stream it never used to touch. If your backend
  has a normal gap of more than 60s between chunks (a long-running tool call, a
  cold start, a slow retrieval hop), you will start seeing a new failure there:
  onError fires with a DOMException named TimeoutError
  ("StreamingController: no chunk received within streamIdleTimeout"), the
  controller moves to error, and whatever the stream had already produced is
  discarded rather than appended to messages. Set streamIdleTimeout: 0
  alongside sendTimeout: 0 to restore the old "never times out" behavior.

  Separately, sendTimeout/streamIdleTimeout now treat ±Infinity as an
  explicit "no timeout" (equivalent to 0) rather than falling back to the
  default — see sanitizeTimeoutMs's own doc comment for the reasoning. Only
  NaN (and other non-finite-but-not-infinite garbage) still falls back to the
  default.

  sanitizeTimeoutMs also now clamps a finite value above 2_147_483_647 (the
  32-bit signed integer setTimeout actually accepts) down to that max, instead
  of passing it straight through. Measured: setTimeout(fn, 2_147_483_648)
  fires after 1ms, not after the enormous delay the caller asked for — the
  value silently overflows the 32-bit argument, so a very long sendTimeout or
  streamIdleTimeout used to fail almost instantly instead of effectively never.
  ±Infinity remains the explicit way to disable a timeout entirely.

@loquix/[email protected]

Patch Changes

• Updated dependencies [a4b5156]
  • @loquix/[email protected]