Bump the production-dependencies group with 2 updates

[dependabot]

Bumps the production-dependencies group with 2 updates: agents and wrangler.

Updates agents from 0.14.5 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

Updates wrangler from 4.98.0 to 4.106.0

Release notes

Sourced from wrangler's releases.

wrangler@4.106.0

Minor Changes

• #14490 75d8cb0 Thanks @​petebacondarwin! - Add wrangler ai-search jobs commands for managing AI Search indexing jobs

  You can now list, trigger, inspect, cancel, and read the logs of indexing jobs for an AI Search instance:

  wrangler ai-search jobs list <instance>
  wrangler ai-search jobs create <instance> --description "manual reindex"
  wrangler ai-search jobs get <instance> <job-id>
  wrangler ai-search jobs cancel <instance> <job-id>
  wrangler ai-search jobs logs <instance> <job-id>
  

  All commands accept --namespace/-n (defaults to default). All commands except cancel also accept --json for clean machine-readable output.

• #14490 75d8cb0 Thanks @​petebacondarwin! - Add --source-jurisdiction to wrangler ai-search create for R2-backed instances

  R2 buckets can live in a specific jurisdiction (for example eu or fedramp). You can now point an AI Search instance at a bucket in one of those jurisdictions:

  wrangler ai-search create my-instance --type r2 --source my-bucket --source-jurisdiction eu

  When run interactively, the R2 source flow also prompts for a jurisdiction and lists (and can create) buckets within it. The value is a free-form string forwarded to the API as source_params.r2_jurisdiction (server-side validated); omit the flag for no specific jurisdiction. This AI Search command is in open beta.

• #14490 75d8cb0 Thanks @​petebacondarwin! - Add auth profiles for managing multiple OAuth logins

  Auth profiles let you maintain separate OAuth logins and bind them to directories, so you can switch between different accounts for different projects without having to re-login.

  For example:

  wrangler auth create work
  wrangler auth activate work ~/projects/work
  wrangler auth create personal
  wrangler auth activate personal ~/projects/personal

  New commands under wrangler auth:

  • wrangler auth create <name> — create or re-authenticate a named profile via OAuth
  • wrangler auth delete <name> — delete a profile and all its directory bindings
  • wrangler auth activate <name> [dir] — bind a profile to a directory (defaults to cwd). Sub-directories will inherit this profile.
  • wrangler auth deactivate [dir] — remove a directory binding
  • wrangler auth list — list all profiles and their corresponding directories

  There is also a new global --profile flag, which you can use to activate a profile for just that command run. Note that if you have CLOUDFLARE_API_TOKEN set, that will still take precedence over all profiles. Any account id settings (via CLOUDFLARE_ACCOUNT_ID or wrangler config) will also still be respected.

• #14490 75d8cb0 Thanks @​petebacondarwin! - Add --strict flag to wrangler versions upload and improve pre-upload safety checks

... (truncated)

Commits

• 13c69dd Version Packages (#14487)
• 75d8cb0 Revert "Version Packages" (#14490)
• 5e6950b Version Packages (#14433)
• e0cc2cb feat(wrangler): add binding overrides to test harness (#14446)
• d292046 Improve R2 error messages to be clearer and more actionable (#14479)
• f10d4ad Bump the workerd-and-workers-types group with 2 updates (#14478)
• 614ce10 feat(wrangler): apply d1 migrations with test harness (#14451)
• 6091d81 fix(wrangler): replace existing resource bindings during creation (#14440)
• ddf3f4c Replace the use of some vitest deprecated utilities with their current counte...
• f4919d0 [wrangler] Abort custom builds on dev teardown (#14462)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions