@mastra/pg 1.28.0-alpha.3 → 1.28.0

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-pg
 description: Documentation for @mastra/pg. Use when working with @mastra/pg APIs, configuration, or implementation.
 metadata:
   package: "@mastra/pg"
-  version: "1.28.0-alpha.3"
+  version: "1.28.0"
 ---
 
 ## When to use

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.28.0-alpha.3",
+  "version": "1.28.0",
   "package": "@mastra/pg",
   "exports": {},
   "modules": {}

package/dist/docs/references/docs-deployment-workers.md

@@ -35,7 +35,10 @@ The orchestration worker requires a PubSub backend that supports pull mode (e.g.
 
 ### Scheduler worker
 
-Polls storage for due cron schedules and publishes `workflow.start` events. It's a producer only, meaning it creates work for the orchestration worker to pick up.
+Polls storage for due cron schedules and publishes a `workflow.start` event for each fire. It's a producer only, meaning it creates work for the orchestration worker to pick up:
+
+- **Split processes**: Scheduled workflows run on the evented engine, and the orchestration worker runs each fire step by step.
+- **In-process mode**: Scheduled workflows run on the default engine. The orchestration worker in the same process runs each fire in-process, the same way a direct `run.start()` does.
 
 The scheduler reads declarative `schedule` fields from your workflow definitions automatically. See [Scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows) for how to declare schedules.
 
@@ -132,6 +135,8 @@ You can also pass a worker name to the CLI. The command sets `MASTRA_WORKERS` in
 mastra worker start orchestration
 ```
 
+Set `MASTRA_WORKERS` on every process in a split deployment, including `false` on the API process. Any value switches workflows that declare `schedule` to the evented engine, and every process must run those workflows on the same engine. See [Scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows). `mastra worker start` without a worker name doesn't set `MASTRA_WORKERS`, so pass a name or set the variable in the process environment.
+
 ## Network architecture
 
 Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain or public URL, including an inbound HTTP route.
@@ -142,7 +147,7 @@ In a split deployment:
 - **Workers connect outbound only**: They pull events from the distributed PubSub backend and read/write to the shared storage database. They don't accept inbound traffic from clients.
 - **The orchestration worker calls the API internally**: It sends step execution requests to the API over the container network using `MASTRA_STEP_EXECUTION_URL`. This is internal service-to-service communication, not a public endpoint.
 
-All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. HTTP routes for worker-related features run on the API server rather than the worker process. One example is token minting for a voice integration.
+All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. HTTP routes for worker-related features run on the API server rather than the worker process. One example is creating a token for a voice integration.
 
 ## Deploy split workers
 

package/dist/docs/references/reference-storage-retention.md

@@ -202,7 +202,7 @@ async function retentionTick() {
 }
 ```
 
-You can also cancel a long-running prune with an `AbortSignal`: the loop stops between batches and returns partial results with `done: false`, so the next run resumes cleanly.
+You can also cancel a long-running prune with an `AbortSignal`: the loop stops between batches and returns partial results with `done: false`. The next run resumes cleanly.
 
 ## ClickHouse native TTL
 

package/dist/index.cjs

@@ -17405,6 +17405,10 @@ const TRACE_FIELDS = {
 	traceId: "r.\"traceId\"",
 	threadId: "r.\"threadId\"",
 	resourceId: "r.\"resourceId\"",
+	runId: "r.\"runId\"",
+	sessionId: "r.\"sessionId\"",
+	userId: "r.\"userId\"",
+	organizationId: "r.\"organizationId\"",
 	startedAt: "r.\"startedAt\"",
 	endedAt: "r.\"endedAt\"",
 	durationMs: durationMsSql("r.\"startedAt\"", "r.\"endedAt\""),
@@ -17429,7 +17433,11 @@ const SPAN_FIELDS = {
 	entityName: "s.\"entityName\"",
 	entityVersionId: "s.\"entityVersionId\"",
 	parentEntityVersionId: "s.\"parentEntityVersionId\"",
-	rootEntityVersionId: "s.\"rootEntityVersionId\""
+	rootEntityVersionId: "s.\"rootEntityVersionId\"",
+	runId: "s.\"runId\"",
+	sessionId: "s.\"sessionId\"",
+	userId: "s.\"userId\"",
+	organizationId: "s.\"organizationId\""
 };
 const SCORE_FIELDS = {
 	scorerId: "s.\"scorerId\"",
@@ -17745,7 +17753,11 @@ function compilePostgresTraceScope(schema, selection, relationCollections, scope
       s."entityName",
       s."entityVersionId",
       s."parentEntityVersionId",
-      s."rootEntityVersionId"
+      s."rootEntityVersionId",
+      s."runId",
+      s."sessionId",
+      s."userId",
+      s."organizationId"
     FROM ${spanTable} s
     WHERE s."traceId" IS NOT NULL
       AND s."traceId" IN (SELECT "traceId" FROM root_scope)
@@ -19088,7 +19100,8 @@ var ObservabilityStoragePostgresVNext = class ObservabilityStoragePostgresVNext
 			"trace-query-discovery",
 			"thread-query",
 			"trace-query-tenant-scope",
-			"feedback"
+			"feedback",
+			"trace-query-context-ids"
 		];
 		return [
 			"metrics",
@@ -19105,7 +19118,8 @@ var ObservabilityStoragePostgresVNext = class ObservabilityStoragePostgresVNext
 			"trace-query-discovery",
 			"thread-query",
 			"trace-query-tenant-scope",
-			"feedback"
+			"feedback",
+			"trace-query-context-ids"
 		];
 	}
 	async #run(op, fn, details) {