Now, all locations that handle DataChunkType properly destructure and return only the allowed properties:

• type (required): The chunk type identifier starting with "data-"
• data (required): The actual data payload
• id (optional): An optional identifier for the chunk

@mastra/core@1.0.0-beta.19

Minor Changes

• Add embedderOptions support to Memory for AI SDK 5+ provider-specific embedding options (#11462)

  With AI SDK 5+, embedding models no longer accept options in their constructor. Options like outputDimensionality for Google embedding models must now be passed when calling embed() or embedMany(). This change adds embedderOptions to Memory configuration to enable passing these provider-specific options.

  You can now configure embedder options when creating Memory:

  import { Memory } from '@mastra/core';
  import { google } from '@ai-sdk/google';
  
  // Before: No way to specify providerOptions
  const memory = new Memory({
    embedder: google.textEmbeddingModel('text-embedding-004'),
  });
  
  // After: Pass embedderOptions with providerOptions
  const memory = new Memory({
    embedder: google.textEmbeddingModel('text-embedding-004'),
    embedderOptions: {
      providerOptions: {
        google: {
          outputDimensionality: 768,
          taskType: 'RETRIEVAL_DOCUMENT',
        },
      },
    },
  });
  

  This is especially important for:

  • Google text-embedding-004: Control output dimensions (default 768)
  • Google gemini-embedding-001: Reduce from default 3072 dimensions to avoid pgvector's 2000 dimension limit for HNSW indexes

  Fixes #8248

Patch Changes

• Fix Anthropic API error when tool calls have empty input objects (#11474)

  Fixes issue #11376 where Anthropic models would fail with error "messages.17.content.2.tool_use.input: Field required" when a tool call in a previous step had an empty object {} as input.

  The fix adds proper reconstruction of tool call arguments when converting messages to AIV5 model format. Tool-result parts now correctly include the input field from the matching tool call, which is required by Anthropic's API validation.

  Changes:

  • Added findToolCallArgs() helper method to search through messages and retrieve original tool call arguments
  • Enhanced aiV5UIMessagesToAIV5ModelMessages() to populate the input field on tool-result parts
  • Added comprehensive test coverage for empty object inputs, parameterized inputs, and multi-turn conversations

• Fixed an issue where deprecated Groq models were shown during template creation. The model selection now filters out models marked as deprecated, displaying only active and supported models. (#11445)

• Fix AI SDK v6 (specificationVersion: "v3") model support in sub-agent calls. Previously, when a parent agent invoked a sub-agent with a v3 model through the agents property, the version check only matched "v2", causing v3 models to incorrectly fall back to legacy streaming methods and throw "V2 models are not supported for streamLegacy" error. (#11452)

  The fix updates version checks in listAgentTools and llm-mapping-step.ts to use the centralized supportedLanguageModelSpecifications array which includes both v2 and v3.

  Also adds missing v3 test coverage to tool-handling.test.ts to prevent regression.

• Fixed "Transforms cannot be represented in JSON Schema" error when using Zod v4 with structuredOutput (#11466)

  When using schemas with .optional(), .nullable(), .default(), or .nullish().default("") patterns with structuredOutput and Zod v4, users would encounter an error because OpenAI schema compatibility layer adds transforms that Zod v4's native toJSONSchema() cannot handle.

  The fix uses Mastra's transform-safe zodToJsonSchema function which gracefully handles transforms by using the unrepresentable: 'any' option.

  Also exported isZodType utility from @mastra/schema-compat and updated it to detect both Zod v3 (_def) and Zod v4 (_zod) schemas.

• Improved test description in ModelsDevGateway to clearly reflect the behavior being tested (#11460)

@mastra/deployer@1.0.0-beta.19

Patch Changes

• Fix npm resolving wrong @mastra/server version (#11467)

  Changed @mastra/server dependency from workspace:^ to workspace:* to prevent npm from resolving to incompatible stable versions (e.g., 1.0.3) instead of the required beta versions.

• Remove extra console log statements in node-modules-extension-resolver (#11470)

@mastra/pg@1.0.0-beta.11

Minor Changes

• Remove pg-promise dependency and use pg.Pool directly (#11450)

  BREAKING CHANGE: This release replaces pg-promise with vanilla node-postgres (pg).

  Breaking Changes

  • Removed store.pgp: The pg-promise library instance is no longer exposed
  • Config change: { client: pgPromiseDb } is no longer supported. Use { pool: pgPool } instead
  • Cloud SQL config: max and idleTimeoutMillis must now be passed via pgPoolOptions

  New Features

  • store.pool: Exposes the underlying pg.Pool for direct database access or ORM integration (e.g., Drizzle)
  • store.db: Provides a DbClient interface with methods like one(), any(), tx(), etc.
  • store.db.connect(): Acquire a client for session-level operations

  Migration

  // Before (pg-promise)
  import pgPromise from 'pg-promise';
  const pgp = pgPromise();
  const client = pgp(connectionString);
  const store = new PostgresStore({ id: 'my-store', client });
  
  // After (pg.Pool)
  import { Pool } from 'pg';
  const pool = new Pool({ connectionString });
  const store = new PostgresStore({ id: 'my-store', pool });
  
  // Use store.pool with any library that accepts a pg.Pool
  

Patch Changes

• Added exportSchemas() function to generate Mastra database schema as SQL DDL without a database connection. (#11448)

  What's New

  You can now export your Mastra database schema as SQL DDL statements without connecting to a database. This is useful for:

  • Generating migration scripts
  • Reviewing the schema before deployment
  • Creating database schemas in environments where the application doesn't have CREATE privileges

  Example

  import { exportSchemas } from '@mastra/pg';
  
  // Export schema for default 'public' schema
  const ddl = exportSchemas();
  console.log(ddl);
  
  // Export schema for a custom schema
  const customDdl = exportSchemas('my_schema');
  // Creates: CREATE SCHEMA IF NOT EXISTS "my_schema"; and all tables within it
  

@mastra/schema-compat@1.0.0-beta.5

Patch Changes

• Fixed "Transforms cannot be represented in JSON Schema" error when using Zod v4 with structuredOutput (#11466)

  When using schemas with .optional(), .nullable(), .default(), or .nullish().default("") patterns with structuredOutput and Zod v4, users would encounter an error because OpenAI schema compatibility layer adds transforms that Zod v4's native toJSONSchema() cannot handle.

  The fix uses Mastra's transform-safe zodToJsonSchema function which gracefully handles transforms by using the unrepresentable: 'any' option.

  Also exported isZodType utility from @mastra/schema-compat and updated it to detect both Zod v3 (_def) and Zod v4 (_zod) schemas.

• fix(schema-compat): handle undefined values in optional fields for OpenAI compat layers (#11469)

  When a Zod schema has nested objects with .partial(), the optional fields would fail validation with "expected string, received undefined" errors. This occurred because the OpenAI schema compat layer converted .optional() to .nullable(), which only accepts null values, not undefined.

  Changed .nullable() to .nullish() so that optional fields now accept both null (when explicitly provided by the LLM) and undefined (when fields are omitted entirely).

  Fixes #11457

Full Changelog: 4837644