build(deps): bump agents from 0.7.6 to 0.17.3

[dependabot]

Bumps agents from 0.7.6 to 0.17.3.

Release notes

Sourced from agents's releases.

agents@0.17.3

Patch Changes

• 58eea18 Thanks @​threepointone! - trigger a release

agents@0.17.1

Patch Changes

• #1826 1bbd9bc Thanks @​threepointone! - Add a tight, OOM-specific retry budget to chat recovery so a memory-limit crash loop seals fast and attributably (#1825).

  When a recovery turn hits a Durable Object memory-limit reset (the isolate exceeded its 128 MB limit), recovery now classifies it as a distinct, deterministic failure rather than a deploy-style transient. A memory reset re-OOMs on re-run (the turn's working set, not the platform, is the cause), so it must NOT be deferred and retried forever like a code-update/connection-lost transient. Each such crash bumps a durable per-incident oomAttempts counter; recovery retries a small number of times (new chatRecovery.maxOomRetries, default 3) — in case the OOM was a transient spike — then seals with reason="out_of_memory". This is far tighter than the generic maxRecoveryWork backstop because an OOM is attributable and each re-run re-runs the model.

  This complements the finite maxRecoveryWork default: the OOM budget is the fast path for memory resets that surface as catchable errors thrown from recovery bookkeeping (e.g. storage/SQL rejections after the reset), while maxRecoveryWork remains a backstop for the hard-kill case where no in-isolate code runs to record the OOM.

  Adds an alarm-boundary circuit breaker (agents) as the universal backstop for the case the in-DO budgets can't catch (#1825): a memory-limit reset that bypasses them entirely — thrown before the budget code runs (e.g. boot-time state hydration OOMs), or whose own small writes also OOM under memory pressure. Left unhandled, such an error propagates out of alarm() and the platform auto-retries the alarm forever, re-running the doomed, billable turn each cycle. Agent.alarm() now intercepts ONLY Durable Object memory-limit resets at the outermost frame — where the heavy turn has unwound and GC has reclaimed its footprint, so the seal/purge writes can land where mid-turn ones OOMed. A durable strike counter tolerates a few resets (new static options.maxAlarmMemoryLimitStrikes, default 3) — backing off the looping rows so the retry is not a hot loop — then seals the recovery (out_of_memory) and surgically purges only the looping schedule rows, leaving unrelated scheduled tasks intact. A new alarm:memory_limit_reset observability event is emitted. Everything except memory-limit resets re-throws exactly as before.

  Also broadens and exports the isDurableObjectMemoryLimitReset(error) predicate from agents (a sibling to isDurableObjectCodeUpdateReset / isPlatformTransientError): it now matches the shared "exceeded its memory limit" fragment so truncated/reworded surfacings (observed in real #1825 logs) still classify.

• #1826 1bbd9bc Thanks @​threepointone! - Fix neverending chat-recovery retries when a Durable Object isolate runs out of memory mid-turn (#1825).

  chatRecovery.maxRecoveryWork now defaults to a generous finite backstop (1000) instead of Infinity. An isolate that exceeds its memory limit and is reset mid-stream has usually already streamed a little content, which bumps the durable progress counter. On the next wake recovery reads that as forward progress and resets both progress-keyed bounds — the attempt cap (maxAttempts) and the no-progress window (noProgressTimeoutMs) — and because each crash lands inside the alarm-debounce window the attempt counter is pinned too. With the work budget disabled (Infinity), no instrument could ever seal the turn, so recovery re-ran the turn (and its LLM calls) forever. The work meter is the one signal that keeps climbing across such a loop, so a finite default seals a runaway with reason="work_budget_exceeded" instead of looping.

  Work only accrues from the first interruption until the turn completes, so a normal interrupted turn never approaches the cap. A very long agentic turn that legitimately produces a large amount of content under heavy interruption can raise maxRecoveryWork (or set it to Infinity to restore the previous fully-unbounded behavior, ideally paired with a shouldKeepRecovering predicate that bounds the runaway via real token/cost accounting).

agents@0.17.0

Minor Changes

• #1758 6b46b04 Thanks @​threepointone! - Add progress signalling and durable milestones for agent-tool sub-agents cloudflare/agents#1758

  A sub-agent running as an agent tool (awaited or detached/background) can now report mid-run progress:

  // Inside the child sub-agent (e.g. from a tool's execute):
  await this.reportProgress({
    fraction: 0.6,
    phase: "deploying",
    message: "Generating menu page…",
  });

  These signals ride the child's own turn stream as a transient data-agent-progress part, so they re-broadcast to the parent's connected clients and surface on AgentToolRunState.progress via useAgentToolEvents — a background-runs tray can render a live bar / phase / status line without drilling in. Highlights:

  • reportProgress({ fraction?, message?, phase?, data? }, { persist? }) on chat agents (@cloudflare/think, AIChatAgent); a no-op with a dev warning on

... (truncated)

Changelog

Sourced from agents's changelog.

0.17.3

Patch Changes

• 58eea18 Thanks @​threepointone! - trigger a release

0.17.2

Patch Changes

• #1836 0544aa2 Thanks @​threepointone! - Fix useAgentToolEvents doubling streamed text in React StrictMode / SSR frameworks (#1835).

  The agent-tool-event reducer (applyAgentToolEvent → applyToRun) shallow-copied a run's parts array with [...seeded.parts] and then handed it to applyChunkToParts, which mutates part objects in place (e.g. lastTextPart.text += delta). Because the copied array still shared its element references with the previous state, those in-place mutations leaked back into prev. React double-invokes setState updaters in StrictMode and during dev hydration, so each text-delta chunk was applied twice against the same already-mutated prev, doubling every word. Affected Next.js, TanStack Start, Remix, and any <React.StrictMode> app. The reducer now clones each part before mutating, keeping it pure.

• #1838 cc21f09 Thanks @​threepointone! - Fix reconnect-driven resume overlap throwing Cannot read properties of undefined (reading 'state') in useAgentChat (#1837).

  With resume: true (the default), the hook re-probes the stream from its WebSocket onAgentOpen handler on every reconnect. The AI SDK's Chat.makeRequest has no concurrency guard — every resume shares the single mutable this.activeResponse, and its finally finalizer reads this.activeResponse.state.message with a bare (unguarded) read before clearing it. Under a reconnect storm (flaky mobile link, or a Durable Object bounce on redeploy), a second resume could overwrite + clear activeResponse before an earlier resume's finalizer ran, so the earlier finalizer read undefined and threw. The old guard didn't close the window: isAwaitingResume() only covers the handshake (it flips false the instant STREAM_RESUMING resolves, before the AI SDK sets status to submitted in a later microtask) and statusRef is lagging React state. Resumes are now serialized via an in-flight flag, so a re-probe resumeStream() is never issued while one is still outstanding.

0.17.1

Patch Changes

• #1826 1bbd9bc Thanks @​threepointone! - Add a tight, OOM-specific retry budget to chat recovery so a memory-limit crash loop seals fast and attributably (#1825).

  When a recovery turn hits a Durable Object memory-limit reset (the isolate exceeded its 128 MB limit), recovery now classifies it as a distinct, deterministic failure rather than a deploy-style transient. A memory reset re-OOMs on re-run (the turn's working set, not the platform, is the cause), so it must NOT be deferred and retried forever like a code-update/connection-lost transient. Each such crash bumps a durable per-incident oomAttempts counter; recovery retries a small number of times (new chatRecovery.maxOomRetries, default 3) — in case the OOM was a transient spike — then seals with reason="out_of_memory". This is far tighter than the generic maxRecoveryWork backstop because an OOM is attributable and each re-run re-runs the model.

  This complements the finite maxRecoveryWork default: the OOM budget is the fast path for memory resets that surface as catchable errors thrown from recovery bookkeeping (e.g. storage/SQL rejections after the reset), while maxRecoveryWork remains a backstop for the hard-kill case where no in-isolate code runs to record the OOM.

  Adds an alarm-boundary circuit breaker (agents) as the universal backstop for the case the in-DO budgets can't catch (#1825): a memory-limit reset that bypasses them entirely — thrown before the budget code runs (e.g. boot-time state hydration OOMs), or whose own small writes also OOM under memory pressure. Left unhandled, such an error propagates out of alarm() and the platform auto-retries the alarm forever, re-running the doomed, billable turn each cycle. Agent.alarm() now intercepts ONLY Durable Object memory-limit resets at the outermost frame — where the heavy turn has unwound and GC has reclaimed its footprint, so the seal/purge writes can land where mid-turn ones OOMed. A durable strike counter tolerates a few resets (new static options.maxAlarmMemoryLimitStrikes, default 3) — backing off the looping rows so the retry is not a hot loop — then seals the recovery (out_of_memory) and surgically purges only the looping schedule rows, leaving unrelated scheduled tasks intact. A new alarm:memory_limit_reset observability event is emitted. Everything except memory-limit resets re-throws exactly as before.

  Also broadens and exports the isDurableObjectMemoryLimitReset(error) predicate from agents (a sibling to isDurableObjectCodeUpdateReset / isPlatformTransientError): it now matches the shared "exceeded its memory limit" fragment so truncated/reworded surfacings (observed in real #1825 logs) still classify.

• #1826 1bbd9bc Thanks @​threepointone! - Fix neverending chat-recovery retries when a Durable Object isolate runs out of memory mid-turn (#1825).

  chatRecovery.maxRecoveryWork now defaults to a generous finite backstop (1000) instead of Infinity. An isolate that exceeds its memory limit and is reset mid-stream has usually already streamed a little content, which bumps the durable progress counter. On the next wake recovery reads that as forward progress and resets both progress-keyed bounds — the attempt cap (maxAttempts) and the no-progress window (noProgressTimeoutMs) — and because each crash lands inside the alarm-debounce window the attempt counter is pinned too. With the work budget disabled (Infinity), no instrument could ever seal the turn, so recovery re-ran the turn (and its LLM calls) forever. The work meter is the one signal that keeps climbing across such a loop, so a finite default seals a runaway with reason="work_budget_exceeded" instead of looping.

  Work only accrues from the first interruption until the turn completes, so a normal interrupted turn never approaches the cap. A very long agentic turn that legitimately produces a large amount of content under heavy interruption can raise maxRecoveryWork (or set it to Infinity to restore the previous fully-unbounded behavior, ideally paired with a shouldKeepRecovering predicate that bounds the runaway via real token/cost accounting).

0.17.0

Minor Changes

• #1758 6b46b04 Thanks @​threepointone! - Add progress signalling and durable milestones for agent-tool sub-agents cloudflare/agents#1758

  A sub-agent running as an agent tool (awaited or detached/background) can now report mid-run progress:

  // Inside the child sub-agent (e.g. from a tool's execute):

... (truncated)

Commits

• 2e50e66 Version Packages (#1843)
• 27bb642 Version Packages (#1828)
• cc21f09 fix(chat): serialize reconnect-driven resumes to stop activeResponse race (#1...
• 0544aa2 fix(agent-tools): clone run parts in reducer so StrictMode does not double te...
• 3b01c02 update deps
• e5e6b57 fix(agent-tools): forward proxied sub-agent tool events stuck at input-availa...
• 688d722 Version Packages (#1822)
• 1bbd9bc fix(chat-recovery): bound Durable Object memory-limit (OOM) crash loops (#182...
• 16f78c6 Harden browser test process teardown
• 59f7bb7 Stabilize browser test process teardown
• Additional commits viewable in compare view

[dependabot]

Superseded by #64.