@mastra/libsql 1.24.0-alpha.2 → 1.24.0

package/dist/docs/SKILL.md

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

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.24.0-alpha.2",
+  "version": "1.24.0",
   "package": "@mastra/libsql",
   "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/docs-memory-overview.md

@@ -202,7 +202,7 @@ Each delegation creates a fresh `threadId` and a deterministic `resourceId` for
 
 > **Note:** Title generation (`generateTitle`) is a top-level thread concern and **isn't** applied to inherited subagent threads. Because each delegation creates an ephemeral thread that no one sees, running title generation for it would waste an LLM call per delegation. To generate titles for a subagent's own threads, give that subagent its own memory configuration.
 
-The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved; the full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/subagents) callback.
+The supervisor forwards its conversation context to the subagent so it has enough background to complete the task. Only the delegation prompt and the subagent's response are saved. The full parent conversation isn't stored. You can control which messages reach the subagent with the [`messageFilter`](https://mastra.ai/docs/subagents) callback.
 
 > **Note:** Subagent resource IDs are always suffixed with the agent name (`{parentResourceId}-{agentName}`). Different subagents under the same supervisor never share a resource ID through delegation.
 

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

@@ -11232,6 +11232,7 @@ var SchedulesLibSQL = class SchedulesLibSQL extends _mastra_core_storage.Schedul
 		});
 	}
 	async init() {
+		await this.#migrateLegacyTriggersTable();
 		await this.#db.createTable({
 			tableName: _mastra_core_storage.TABLE_SCHEDULES,
 			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_SCHEDULES]
@@ -11240,6 +11241,15 @@ var SchedulesLibSQL = class SchedulesLibSQL extends _mastra_core_storage.Schedul
 			tableName: _mastra_core_storage.TABLE_SCHEDULE_TRIGGERS,
 			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS]
 		});
+		try {
+			await this.#db.alterTable({
+				tableName: _mastra_core_storage.TABLE_SCHEDULES,
+				schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_SCHEDULES],
+				ifNotExists: ["owner_type", "owner_id"]
+			});
+		} catch (error) {
+			if (!(await this.#db.hasColumn(_mastra_core_storage.TABLE_SCHEDULES, "owner_type") && await this.#db.hasColumn(_mastra_core_storage.TABLE_SCHEDULES, "owner_id"))) throw error;
+		}
 		await this.#client.batch([{
 			sql: `CREATE INDEX IF NOT EXISTS idx_schedules_status_next_fire ON "${_mastra_core_storage.TABLE_SCHEDULES}" ("status", "next_fire_at")`,
 			args: []
@@ -11248,6 +11258,42 @@ var SchedulesLibSQL = class SchedulesLibSQL extends _mastra_core_storage.Schedul
 			args: []
 		}], "write");
 	}
+	/**
+	* Trigger tables created before the ownership/audit schema change are keyed
+	* by `run_id` (NOT NULL) and store `status` instead of `outcome`. SQLite
+	* cannot change a primary key or rename-and-retype in place, so the table is
+	* rebuilt in the current shape inside one write transaction. Legacy run ids
+	* are unique, so they become the new row ids.
+	*/
+	async #migrateLegacyTriggersTable() {
+		const isLegacy = async () => await this.#db.hasColumn(_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS, "status") && !await this.#db.hasColumn(_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS, "outcome");
+		if (!await isLegacy()) return;
+		const shadow = `${_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS}__legacy_rebuild`;
+		try {
+			await this.#client.batch([
+				`DROP TABLE IF EXISTS "${shadow}"`,
+				`CREATE TABLE "${shadow}" (
+            "id" TEXT NOT NULL PRIMARY KEY,
+            "schedule_id" TEXT NOT NULL,
+            "run_id" TEXT,
+            "scheduled_fire_at" INTEGER NOT NULL,
+            "actual_fire_at" INTEGER NOT NULL,
+            "outcome" TEXT NOT NULL,
+            "error" TEXT,
+            "trigger_kind" TEXT NOT NULL,
+            "parent_trigger_id" TEXT,
+            "metadata" TEXT
+          )`,
+				`INSERT INTO "${shadow}" ("id", "schedule_id", "run_id", "scheduled_fire_at", "actual_fire_at", "outcome", "error", "trigger_kind")
+           SELECT "run_id", "schedule_id", "run_id", "scheduled_fire_at", "actual_fire_at", "status", "error", 'schedule-fire'
+           FROM "${_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS}"`,
+				`DROP TABLE "${_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS}"`,
+				`ALTER TABLE "${shadow}" RENAME TO "${_mastra_core_storage.TABLE_SCHEDULE_TRIGGERS}"`
+			], "write");
+		} catch (error) {
+			if (await isLegacy()) throw error;
+		}
+	}
 	async dangerouslyClearAll() {
 		await this.#db.deleteData({ tableName: _mastra_core_storage.TABLE_SCHEDULE_TRIGGERS });
 		await this.#db.deleteData({ tableName: _mastra_core_storage.TABLE_SCHEDULES });