@mastra/observability 1.17.5-alpha.0 → 1.17.5-alpha.2

package/dist/index.js

@@ -2,7 +2,7 @@ import { createRequire } from "module";
 import { MastraBase } from "@mastra/core/base";
 import { ErrorCategory, ErrorDomain, MastraError } from "@mastra/core/error";
 import { ConsoleLogger, LogLevel, RegisteredLogger } from "@mastra/core/logger";
-import { DEFAULT_BLOCKED_LABELS, EntityType, InternalSpans, SpanType, TracingEventType, generateSignalId, noOpLoggerContext, resolveExportedSpanId } from "@mastra/core/observability";
+import { DEFAULT_BLOCKED_LABELS, EntityType, InternalSpans, SpanType, TracingEventType, noOpLoggerContext } from "@mastra/core/observability";
 import { fetchWithRetry, getNestedValue, setNestedValue } from "@mastra/core/utils";
 import { z } from "zod/v4";
 import fs from "fs";
@@ -862,13 +862,76 @@ const observabilityRegistryConfigSchema = z.object({
 	return true;
 }, { message: "A \"configSelector\" requires at least one config or default observability to be configured." });
 //#endregion
-//#region src/context/logger.ts
+//#region src/ids.ts
+/**
+* Signal and span id helpers.
+*
+* These two utilities also exist in `@mastra/core/observability`. This package
+* deliberately keeps local copies rather than importing them.
+*
+* Importing a helper from core ties this package's real minimum core version to
+* whichever release happened to add that helper. A named ESM import of an export
+* that does not exist fails at link time, before any application code runs, so
+* the mismatch surfaces as a startup crash rather than a resolvable install
+* error. That is how `resolveExportedSpanId` (added in `@mastra/core@1.63.0`)
+* broke deployments pinned to an older core while the declared peer floor still
+* said `>=1.16.0`; `generateSignalId` (added in `@mastra/core@1.26.0`) had
+* already raised the true floor the same way, unnoticed.
+*
+* Both helpers are self-contained: `generateSignalId` wraps `crypto.randomUUID`,
+* and `resolveExportedSpanId` is structurally typed against an optional method
+* rather than any core class. A local copy costs a few lines and lets the
+* declared peer range stay honest.
+*
+* Keep them local. Re-importing either from core silently raises this package's
+* minimum core version again.
+*
+* TODO(mastra-v2): delete this file and import both helpers from
+* `@mastra/core/observability` again.
+*
+* The duplication exists only because a peer floor cannot be raised inside a
+* major version without breaking consumers pinned to an older core. A v2
+* release resets that floor anyway, so importing from core stops being a
+* compatibility hazard at that point. On v2:
+*
+*   1. Set the `@mastra/core` peer range to the v2 line.
+*   2. Re-point the four import sites -- `generateSignalId` in
+*      `context/logger.ts`, `context/metrics.ts` and `recorded.ts`, and
+*      `resolveExportedSpanId` in `instances/base.ts`.
+*   3. Delete this file.
+*
+* Do not undo it before then: both helpers are still missing from cores inside
+* this package's currently declared range (`generateSignalId` landed in core
+* 1.26.0, `resolveExportedSpanId` in 1.63.0, floor is 1.16.0).
+*
+* Context: https://github.com/mastra-ai/mastra/issues/22885
+*/
+/** Generate a unique id for an observability signal (log, metric, score, feedback). */
+function generateSignalId() {
+	return crypto.randomUUID();
+}
 /**
-* LoggerContextImpl - Structured logging with automatic trace correlation.
+* Resolve the spanId an observability signal should reference for a span.
 *
-* Emits LogEvent to the ObservabilityBus. All context (correlationContext,
-* metadata) is snapshotted at construction time.
+* Signals (logs, metrics, and a suspending run's resume link) must name a span
+* that actually reached exporters. An internal or excluded span is never stored,
+* so referencing its raw id leaves the signal pointing at nothing: log/metric
+* span lookups 404, and a resumed run's exported children inherit a dangling
+* parentSpanId and land as orphans. `undefined` is a valid answer, omitting the
+* reference rather than pointing it at a span that does not exist.
+*
+* `getExportedSpanId` is optional on the `Span` interface, so the typeof guard
+* separates "this implementation predates the method" (keep the old behavior of
+* referencing the span's own id) from "the method ran and found nothing
+* exportable" (undefined). Without it the two collapse and custom span
+* implementations silently lose correlation.
 */
+function resolveExportedSpanId(span) {
+	if (!span) return void 0;
+	return typeof span.getExportedSpanId === "function" ? span.getExportedSpanId() : span.id;
+}
+//#endregion
+//#region src/context/logger.ts
 /** Numeric priority used to compare log levels against the configured minimum. */
 const LOG_LEVEL_PRIORITY = {
 	debug: 0,
@@ -939,13 +1002,6 @@ var LoggerContextImpl = class {
 //#endregion
 //#region src/context/metrics.ts
 /**
-* MetricsContextImpl - User-facing metric emission API.
-*
-* All metrics are validated, cardinality-filtered, and constructed here
-* before being routed through ObservabilityBus.emit().
-* CorrelationContext and metadata are snapshotted at construction time.
-*/
-/**
 * User-facing metric emission API. All metrics are routed through
 * ObservabilityBus.emit() after validation and cardinality filtering.
 */