[sander-su]

Closes #2874 (follow-up to the discussion there).

Summary

@ag-ui/mastra pulled in a nested zod@3 copy only through @ai-sdk/ui-utils, which is an AI SDK v4-era package that peers zod ^3.23.8 (every published version, including the latest 1.2.11). The adapter used exactly one symbol from it: parsePartialJson. Apps on Zod 4 therefore got a duplicate Zod 3 plus the ERESOLVE overriding peer dependency warning described in the issue.

This PR:

• drops @ai-sdk/ui-utils
• imports parsePartialJson from the current AI SDK (ai, which peers zod ^3.25.76 || ^4.1.8)
• widens the adapter's own zod dependency from ^3.25.76 to ^3.25.76 || ^4.0.0 (same 3.x floor, matching @mastra/core / @mastra/client-js)

The sync → async change

The current AI SDK only ships an async parsePartialJson (Promise<{ value, state }>, same shape otherwise). Its single caller, parseStreamingWorkingMemoryUpdate, runs inside the chunk pipeline, so that chain is now async and awaited at its call sites:

parseStreamingWorkingMemoryUpdate → processChunk → releaseDeferredReplay (its .some() short-circuit becomes an awaited for…of with the same early return) → handleChunk → the flush returned by createChunkProcessor.

No public API change. None of these functions are exported. createChunkProcessor is private, the emitted .d.ts contains none of their signatures, and MastraAgent's public methods already returned Observables/Promises. Both drivers already awaited the callback (@mastra/client-js's processDataStream does await onChunk(chunk); the local path is a for await loop), so chunk ordering is unchanged.

Cancellation (#2288): why the abort listener now defers subscriber.complete()

Making the pipeline async surfaced an ordering issue in the #2288 remote-cancellation guarantee. cancellation-remote-producer.test.ts > still cancels the run when the caller's controller aborts failed: the producer had delivered 1 chunk and had not stopped (stoppedEarly === false), yet the run had already settled.

Cause: when the run is aborted mid-stream the producer is suspended in await onChunk(...). The abort listener called subscriber.complete() synchronously, so the run settled before the producer resumed and re-checked its aborted signal. With the previously sync pipeline the producer happened to win that race.

Fix: the abort listener now settles the Observable on the next macrotask (setTimeout(…, 0)). Pending microtasks, the producer's resumption included, run first, so the producer observes the abort and stops before the run settles. The reasoning is also documented inline in the listener.

Trade-offs I'd like a maintainer's view on:

• It orders by the event loop, not by an explicit handshake with the producer. In production the per-run handle also aborts the underlying fetch, which tears the stream down regardless; the deferral restores the "producer stopped before the run settles" ordering the [Bug]: MastraAgent Observable run() never propagates cancellation — stopping a run from the client does not stop generation #2288 tests assert.
• There is a one-tick window between abort and completion in which a chunk already being processed may still emit an event to the subscriber. The consumption loops stop pulling new chunks as soon as they see the aborted signal. No existing test covers this window.
• It applies to local and remote runs alike: a cancelled run of either kind now settles one tick later.

If you'd prefer an explicit guard (stop emitting once abortSignal.aborted, plus an explicit producer-stopped handshake) over the timer, I'm happy to rework it that way.

Testing

Run locally in integrations/mastra/typescript:

• pnpm typecheck: clean
• pnpm test: 31 files / 522 tests passed, including the full cancellation-remote-producer, cancellation, state-delta and working-memory-sync suites
• pnpm build: clean
• lockfile validated with pnpm install --frozen-lockfile --filter @ag-ui/mastra

Not done: the full monorepo test matrix (only @ag-ui/mastra is touched). The lockfile diff includes the ai@5 subtree and pnpm's re-resolution of zod-peering packages; happy to regenerate it with your registry setup if CI prefers.

[sander-su]

Superseded by #3224.

Following the preference for a synchronous parser on #3096, and the way Mastra fixed the same dependency in mastra-ai/mastra#27297, #3224 vendors Mastra's sync parsePartialJson instead of importing it from ai@5. That removes the async chunk pipeline and the cancellation setTimeout this PR needed (#2288), and avoids the undici@5 advisories that every ai@5 release brings in through @ai-sdk/provider-utils@3.0.x.

Closing this one so the review can continue on #3224.