Changelog

@mastra/clickhouse@1.0.0-beta.12

Patch Changes

• Fixed duplicate spans migration issue across all storage backends. When upgrading from older versions, existing duplicate (traceId, spanId) combinations in the spans table could prevent the unique constraint from being created. The migration deduplicates spans before adding the constraint. (#12073)

  Deduplication rules (in priority order):

  1. Keep completed spans (those with endedAt set) over incomplete spans
  2. Among spans with the same completion status, keep the one with the newest updatedAt
  3. Use createdAt as the final tiebreaker

  What changed:

  • Added migrateSpans() method to observability stores for manual migration
  • Added checkSpansMigrationStatus() method to check if migration is needed
  • All stores use optimized single-query deduplication to avoid memory issues on large tables

  Usage example:

  const observability = await storage.getStore('observability');
  const status = await observability.checkSpansMigrationStatus();
  if (status.needsMigration) {
    const result = await observability.migrateSpans();
    console.log(`Migration complete: ${result.duplicatesRemoved} duplicates removed`);
  }

  Fixes #11840

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/client-js@1.0.0-beta.26

Patch Changes

• Improve type handling with Zod (#12091)

@mastra/cloudflare@1.0.0-beta.13

Patch Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/cloudflare-d1@1.0.0-beta.12

Patch Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/codemod@1.0.0-beta.8

Major Changes

• Mark as stable (#12096)

@mastra/convex@1.0.0-beta.10

Major Changes

• Mark as stable (#12096)

Patch Changes

• Fixed ConvexStore so storage.getStore(domain) works properly, preventing runtime errors in flows that access domain stores. (#12065)
  Added no-op schema methods (createTable, alterTable) to keep storage migrations compatible with Convex's declarative schema.
  Relates to #11361.

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/core@1.0.0-beta.26

Major Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

Patch Changes

• Improve type handling with Zod (#12091)

@mastra/dynamodb@1.0.0-beta.12

Patch Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/express@1.0.0-beta.21

Major Changes

• Mark as stable (#12096)

@mastra/fastify@1.0.0-beta.21

Major Changes

• Mark as stable (#12096)

@mastra/hono@1.0.0-beta.21

Major Changes

• Mark as stable (#12096)

@mastra/koa@1.0.0-beta.21

Major Changes

• Mark as stable (#12096)

@mastra/lance@1.0.0-beta.13

Patch Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/libsql@1.0.0-beta.14

Patch Changes

• Fixed duplicate spans migration issue across all storage backends. When upgrading from older versions, existing duplicate (traceId, spanId) combinations in the spans table could prevent the unique constraint from being created. The migration deduplicates spans before adding the constraint. (#12073)

  Deduplication rules (in priority order):

  1. Keep completed spans (those with endedAt set) over incomplete spans
  2. Among spans with the same completion status, keep the one with the newest updatedAt
  3. Use createdAt as the final tiebreaker

  What changed:

  • Added migrateSpans() method to observability stores for manual migration
  • Added checkSpansMigrationStatus() method to check if migration is needed
  • All stores use optimized single-query deduplication to avoid memory issues on large tables

  Usage example:

  const observability = await storage.getStore('observability');
  const status = await observability.checkSpansMigrationStatus();
  if (status.needsMigration) {
    const result = await observability.migrateSpans();
    console.log(`Migration complete: ${result.duplicatesRemoved} duplicates removed`);
  }

  Fixes #11840

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/mongodb@1.0.0-beta.14

Patch Changes

• Fixed duplicate spans migration issue across all storage backends. When upgrading from older versions, existing duplicate (traceId, spanId) combinations in the spans table could prevent the unique constraint from being created. The migration deduplicates spans before adding the constraint. (#12073)

  Deduplication rules (in priority order):

  1. Keep completed spans (those with endedAt set) over incomplete spans
  2. Among spans with the same completion status, keep the one with the newest updatedAt
  3. Use createdAt as the final tiebreaker

  What changed:

  • Added migrateSpans() method to observability stores for manual migration
  • Added checkSpansMigrationStatus() method to check if migration is needed
  • All stores use optimized single-query deduplication to avoid memory issues on large tables

  Usage example:

  const observability = await storage.getStore('observability');
  const status = await observability.checkSpansMigrationStatus();
  if (status.needsMigration) {
    const result = await observability.migrateSpans();
    console.log(`Migration complete: ${result.duplicatesRemoved} duplicates removed`);
  }

  Fixes #11840

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/mssql@1.0.0-beta.13

Patch Changes

• Fixed duplicate spans migration issue across all storage backends. When upgrading from older versions, existing duplicate (traceId, spanId) combinations in the spans table could prevent the unique constraint from being created. The migration deduplicates spans before adding the constraint. (#12073)

  Deduplication rules (in priority order):

  1. Keep completed spans (those with endedAt set) over incomplete spans
  2. Among spans with the same completion status, keep the one with the newest updatedAt
  3. Use createdAt as the final tiebreaker

  What changed:

  • Added migrateSpans() method to observability stores for manual migration
  • Added checkSpansMigrationStatus() method to check if migration is needed
  • All stores use optimized single-query deduplication to avoid memory issues on large tables

  Usage example:

  const observability = await storage.getStore('observability');
  const status = await observability.checkSpansMigrationStatus();
  if (status.needsMigration) {
    const result = await observability.migrateSpans();
    console.log(`Migration complete: ${result.duplicatesRemoved} duplicates removed`);
  }

  Fixes #11840

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/pg@1.0.0-beta.15

Patch Changes

• Fixed duplicate spans migration issue across all storage backends. When upgrading from older versions, existing duplicate (traceId, spanId) combinations in the spans table could prevent the unique constraint from being created. The migration deduplicates spans before adding the constraint. (#12073)

  Deduplication rules (in priority order):

  1. Keep completed spans (those with endedAt set) over incomplete spans
  2. Among spans with the same completion status, keep the one with the newest updatedAt
  3. Use createdAt as the final tiebreaker

  What changed:

  • Added migrateSpans() method to observability stores for manual migration
  • Added checkSpansMigrationStatus() method to check if migration is needed
  • All stores use optimized single-query deduplication to avoid memory issues on large tables

  Usage example:

  const observability = await storage.getStore('observability');
  const status = await observability.checkSpansMigrationStatus();
  if (status.needsMigration) {
    const result = await observability.migrateSpans();
    console.log(`Migration complete: ${result.duplicatesRemoved} duplicates removed`);
  }

  Fixes #11840

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

@mastra/playground-ui@7.0.0-beta.26

Patch Changes

• Fixed scorer eligibility check in observability to also check span.entityType field (#12078)

@mastra/server@1.0.0-beta.26

Patch Changes

• Improve type handling with Zod (#12091)

@mastra/upstash@1.0.0-beta.13

Patch Changes

• Renamed MastraStorage to MastraCompositeStore for better clarity. The old MastraStorage name remains available as a deprecated alias for backward compatibility, but will be removed in a future version. (#12093)

  Migration:

  Update your imports and usage:

  // Before
  import { MastraStorage } from '@mastra/core/storage';
  
  const storage = new MastraStorage({
    id: 'composite',
    domains: { ... }
  });
  
  // After
  import { MastraCompositeStore } from '@mastra/core/storage';
  
  const storage = new MastraCompositeStore({
    id: 'composite',
    domains: { ... }
  });

  The new name better reflects that this is a composite storage implementation that routes different domains (workflows, traces, messages) to different underlying stores, avoiding confusion with the general "Mastra Storage" concept.

mastra@1.0.0-beta.18

Minor Changes

• Added mastra migrate CLI command to manually run storage migrations. This command bundles and executes the migration script against your configured storage backend, deduplicating spans and adding unique constraints. Useful when upgrading from older versions that may have duplicate (traceId, spanId) entries. (#12073)

  Usage:

  npx mastra migrate

  Options:

  • -d, --dir <path> - Path to your Mastra folder (default: src/mastra)
  • -r, --root <path> - Path to your root folder
  • -e, --env <env> - Custom env file to include
  • --debug - Enable debug logs

Full Changelog: 08a0faf