build(deps): bump @mastra/observability from 1.3.1 to 1.11.0

[dependabot]

Bumps @mastra/observability from 1.3.1 to 1.11.0.

Release notes

Sourced from @​mastra/observability's releases.

March 11, 2026

Highlights

Dynamic Model Fallback Arrays (Runtime Routing)

Agents can now use model functions that return full fallback arrays (ModelWithRetries[]), enabling context-driven model routing (tier/region/etc.) with nested/async selection and proper maxRetries inheritance.

Standard Schema + Zod v4 Compatibility Layer

Mastra adds Standard Schema normalization (toStandardSchema, standardSchemaToJSONSchema) across Zod v3/v4, AI SDK Schema, and JSON Schema via @mastra/schema-compat, unifying schema handling and improving strict-mode provider compatibility.

Customizable Request Validation Errors Across All Server Adapters

New onValidationError hook on ServerConfig and createRoute() lets you control status codes and response bodies for Zod validation failures, supported consistently in Hono/Express/Fastify/Koa adapters.

RequestContext End-to-End (Tracing + Datasets/Experiments + Storage)

requestContext is now captured on tracing spans (and persisted in ClickHouse/PG/LibSQL/MSSQL span tables) and is supported on dataset items and experiments, allowing request-scoped metadata (tenant/user/flags) to flow through evaluation and observability.

Faster & More Flexible Storage: Recall Performance + PgVector Indexing + New Vector Types

Semantic recall is significantly faster across multiple adapters (notably Postgres for very large threads), PgVector adds metadataIndexes for btree indexing filtered metadata fields, and @mastra/pg now supports pgvector bit and sparsevec vector types.

Breaking Changes

• Minimum Zod version is now ^3.25.0 (for v3) or ^4.0.0 (for v4 support).

Changelog

@​mastra/core@​1.11.0

Minor Changes

• feat: support dynamic functions returning model fallback arrays (#11975)

  Agents can now use dynamic functions that return entire fallback arrays based on runtime context. This enables:

  • Dynamic selection of complete fallback configurations
  • Context-based model selection with automatic fallback
  • Flexible model routing based on user tier, region, or other factors
  • Nested dynamic functions within returned arrays (each model in array can also be dynamic)

  Examples

  Basic dynamic fallback array

  const agent = new Agent({
    model: ({ requestContext }) => {
      const tier = requestContext.get('tier');
      if (tier === 'premium') {
        return [
          { model: 'openai/gpt-4', maxRetries: 2 },
          { model: 'anthropic/claude-3-opus', maxRetries: 1 },
        ];
      }
      return [{ model: 'openai/gpt-3.5-turbo', maxRetries: 1 }];
    },

... (truncated)

Changelog

Sourced from @​mastra/observability's changelog.

1.11.0

Minor Changes

• Auto-attach the Mastra-level environment to all observability signals. (#15956)

Patch Changes

• Updated dependencies [1723e09, 629f9e9, 25168fb, ab34b5a, 5fb6c2a, 2b0f355, 394f0cf, b2deb29, 66644be, e109607, 310b953, 3d7f709, 48a42f1, 8091c7c, 2c83efc, 43f0e1d, da0b9e2, 282a10c, 04151c7, 8091c7c]:
  • @​mastra/core@​1.31.0

1.11.0-alpha.0

Minor Changes

• Auto-attach the Mastra-level environment to all observability signals. (#15956)

Patch Changes

• Updated dependencies [1723e09, 629f9e9, 25168fb, ab34b5a, 5fb6c2a, 394f0cf, 3d7f709, 48a42f1, 2c83efc, 282a10c]:
  • @​mastra/core@​1.31.0-alpha.0

1.10.3

Patch Changes

• Add durable agents with resumable streams (#12557)

  Durable agents make agent execution resilient to disconnections, crashes, and long-running operations.

  The Problem

  Standard agent streaming has two fragility points:

  1. Connection drops - If a client disconnects mid-stream (network blip, browser refresh, mobile app backgrounded), all subsequent events are lost. The client has no way to "catch up" on what they missed.
  2. Long-running operations - Agent loops with tool calls can take minutes. Holding an HTTP connection open that long is unreliable. If the server restarts or the connection times out, the work is lost.

  The Solution

  Resumable streams solve connection drops. Every event is cached with a sequential index. If a client disconnects at event 5, they can reconnect and request events starting from index 6. They receive cached events immediately, then continue with live events as they arrive.

  Durable execution solves long-running operations. Instead of executing the agent loop directly in the HTTP request, execution happens in a workflow engine (built-in evented engine or Inngest). The HTTP request just subscribes to events. If the connection drops, execution continues. The client can reconnect anytime to observe progress.

  Usage

  Wrap any existing Agent with durability using factory functions:

  import { Agent } from '@mastra/core/agent';
  import { createDurableAgent } from '@mastra/core/agent/durable';

... (truncated)

Commits

• 3ec9acb chore: version - exit prerelease mode
• e19c4e5 chore: version packages (alpha) (#15979)
• 282a10c Add top-level environment config to Mastra for observability tagging (#15956)
• 9119f5c chore: version - exit prerelease mode
• 3b11cdd chore: version packages (alpha) (#15940)
• f8694b6 feat(core,inngest): durable agent architecture with resumable streams (#12557)
• 496e11d feat(observability): reduce default cloud event volume (#15815)
• f90c8ab chore: version - exit prerelease mode
• 7179450 chore: version packages (alpha) (#15909)
• 808df1b fix(core): aggregate Anthropic cache-write tokens across multi-step runs (#15...
• Additional commits viewable in compare view