@mastra/libsql 1.22.3-alpha.3 → 1.22.4-alpha.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.22.3-alpha.3"
+  version: "1.22.4-alpha.0"
 ---
 
 ## When to use

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.22.3-alpha.3",
+  "version": "1.22.4-alpha.0",
   "package": "@mastra/libsql",
   "exports": {},
   "modules": {}

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

@@ -39,6 +39,12 @@ Polls storage for due cron schedules and publishes `workflow.start` events. It's
 
 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.
 
+The scheduler only polls storage once a schedule exists. At boot, a process with no declared schedules runs a single `listSchedules()` check. If that check finds no rows, the poll loop never starts, so idle deployments issue no recurring scheduler queries and can scale to zero.
+
+When a schedule is created at runtime, Mastra publishes a wake event on the PubSub backend. Any process running the default worker set starts its scheduler in response, which is how a standalone worker discovers schedules created by the API process. This requires both processes to share the same PubSub backend.
+
+To poll from startup regardless of whether schedules exist (for example, when your processes don't share a PubSub backend), set `scheduler: { enabled: true }` on the worker or run it with `MASTRA_WORKERS=scheduler`.
+
 **Don't run more than one scheduler instance.** Multiple schedulers polling the same storage would fire duplicate events for the same schedule.
 
 ### Background task worker
@@ -279,6 +285,8 @@ curl http://localhost:4111/api/agents
 
 ### Kubernetes
 
+> **Helm:** On Kubernetes, the [`mastra-projects` Helm chart](https://mastra.ai/integrations/deploy/kubernetes-helm) renders these deployments for you, with the workers on the same image and environment as the server. It also refuses to install combinations that would run every worker twice. The manifests below are for writing them by hand.
+
 Create separate Deployments for the API, orchestration worker, scheduler worker, and background task worker. Use the same image and Secret for each Deployment. Set only the role-specific environment variables directly on each container.
 
 The orchestration worker Deployment has the following shape:
@@ -385,4 +393,5 @@ If the API crashes while a step is executing, that work can be lost and the work
 - [Workers reference](https://mastra.ai/reference/workers/overview): Details about worker environment variables and types, with a list of supported storage backends
 - [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`
 - [PubSub](https://mastra.ai/docs/server/pubsub): Event delivery backends
+- [Kubernetes (Helm)](https://mastra.ai/integrations/deploy/kubernetes-helm): Deploy worker roles with the official chart
 - [Scheduled workflows](https://mastra.ai/docs/workflows/scheduled-workflows): Declare cron schedules on workflows

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

@@ -205,6 +205,7 @@ Each provider page includes installation instructions, configuration parameters,
 - [libSQL](https://mastra.ai/integrations/databases/libsql)
 - [Mastra](https://mastra.ai/docs/mastra-platform/database)
 - [MongoDB](https://mastra.ai/integrations/databases/mongodb)
+- [MySQL](https://mastra.ai/integrations/databases/mysql)
 - [MSSQL](https://mastra.ai/integrations/databases/mssql)
 - [Neon Postgres](https://mastra.ai/integrations/databases/neon)
 - [OracleDB](https://mastra.ai/integrations/databases/oracledb)

package/dist/docs/references/reference-core-mastra-class.md

@@ -125,7 +125,7 @@ Visit the [Configuration reference](https://mastra.ai/reference/configuration) f
 
 **backgroundTasks.defaultRetries** (`RetryConfig`): Default retry configuration.
 
-**scheduler** (`object`): Configure the scheduler worker for cron-driven workflow triggers. Auto-enables when any workflow declares a schedule. See Scheduled workflows.
+**scheduler** (`object`): Configure the scheduler worker for cron-driven workflow triggers. Auto-enables when any workflow declares a schedule, when schedule rows already exist in storage, or when a schedule is created at runtime. Apps that never schedule anything run one listSchedules() check at boot and never poll after that. See Scheduled workflows.
 
 **scheduler.enabled** (`boolean`): Explicitly enable or disable the scheduler.
 

package/dist/index.cjs

@@ -9353,6 +9353,10 @@ var MemoryLibSQL = class MemoryLibSQL extends _mastra_core_storage.MemoryStorage
 					} catch {
 						existingChunks = [];
 					}
+					if (existingChunks.some((existing) => existing.cycleId === input.chunk.cycleId)) {
+						await tx.commit();
+						return;
+					}
 					const newChunk = {
 						id: `ombuf-${(0, crypto$1.randomUUID)()}`,
 						cycleId: input.chunk.cycleId,
@@ -10459,6 +10463,7 @@ var ObservabilityLibSQL = class ObservabilityLibSQL extends _mastra_core_storage
 		}
 	}
 	async batchDeleteTraces(args) {
+		this.assertUnscopedBatchDeleteTraces(args);
 		try {
 			const keys = args.traceIds.map((traceId) => ({ traceId }));
 			return this.#db.batchDelete({