fix(deps): update dependency @mastra/libsql to v1

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@mastra/libsql (source)	^0.12.0 → ^1.0.0

---

Release Notes

mastra-ai/mastra (@​mastra/libsql)

v1.15.0

Compare Source

Minor Changes

• Added storage retention support to libSQL. When you set a retention config, LibSQLStore can prune old rows from every growth-table domain: memory (threads, messages, resources by createdAt), threadState (by updatedAt), observability (spans by startedAt), scores (by createdAt), workflows (run snapshots by updatedAt), backgroundTasks (by completedAt, so in-flight tasks are never pruned), experiments (whole runs by completedAt, results cascade with their parent), notifications and harness sessions (by createdAt), and schedules fire history (by actual_fire_at). (#​18733)

  Deletes run in batches so they stay safe on large tables. Anchor-column indexes are created lazily on the first prune() call — never at init — so deployments that don't configure retention pay no extra index overhead. prune() only deletes rows; reclaiming disk (for example a VACUUM on self-hosted libSQL) is left to you to run in a maintenance window.

  const storage = new LibSQLStore({
    id: 'mastra-storage',
    url: 'file:./mastra.db',
    retention: {
      memory: { messages: { maxAge: '30d' } },
      observability: { spans: { maxAge: '7d' } },
    },
  });
  
  await storage.prune();

Patch Changes

• Added optional tenancy arguments to getDataset, updateDataset, and deleteDataset. (#​18750)

  You can now pass organizationId and projectId to scope dataset reads, updates, and deletes to a specific tenant. Reads and updates against a dataset in a different tenant throw DATASET_NOT_FOUND (surfaced as a 404 over HTTP). Deletes silently no-op on a tenancy mismatch — matching the existing "delete non-existent id is a no-op" semantics so cross-tenant existence is never leaked via error timing or status.

  Example

  // Before
  await client.getDataset('abc123');
  await client.deleteDataset('abc123');
  await client.updateDataset({ id: 'abc123', name: 'renamed' });
  
  // After — scope to a tenant
  await client.getDataset('abc123', { organizationId: 'org_a', projectId: 'proj_1' });
  await client.deleteDataset('abc123', { organizationId: 'org_a' });
  await client.updateDataset({ id: 'abc123', name: 'renamed', organizationId: 'org_a' });

• Pushed remaining dataset read filters and pagination down to storage. (#​18710)

  DatasetsManager.list({ filters }) now accepts targetType, targetIds (overlap/union semantics), and name (substring, case-insensitive) in addition to the existing tenancy and candidate filters. Filtering is pushed down to the storage layer so callers no longer have to post-filter results.

  Storage adapters must also be upgraded to the versions listed below to honor the new filters. If a caller is on this version of @mastra/core but on an older storage adapter, the new targetType/targetIds/name filter keys are silently ignored by the adapter — no runtime error, but the filter has no effect and every dataset in the tenancy is returned.

  Dataset.listItems({ version, search, page, perPage }) now applies search and pagination at the storage layer when version is provided alongside any of those. Previously they were silently dropped whenever version was set. The return shape is unchanged: passing only version still returns a bare DatasetItem[] snapshot; passing search, page, or perPage (with or without version) returns the paginated { items, pagination } shape. The bare-array branch is marked @deprecated; prefer passing page / perPage to always receive the paginated shape.

• Fixed a double-encoding bug where createDataset stored targetIds and scorerIds as JSON-encoded strings instead of arrays. This caused the new listDatasets({ filters: { targetIds } }) overlap query to never match. (#​18710)

  Existing rows written before this fix are still double-encoded and will not be matched by the new targetIds filter. They self-heal on the next updateDataset call. Deployments with a long tail of pre-existing datasets should run a one-time backfill (re-encoding targetIds and scorerIds on affected rows) rather than rely on incidental writes; this can be tracked as a follow-up if needed.

• Tenancy-scope experiments getById and delete* on ExperimentsStorage. (#​18770)

  ExperimentsStorage.getExperimentById, getExperimentResultById, deleteExperiment, and deleteExperimentResults used to key on the primary id alone, so any caller who knew the id could read or delete the row regardless of tenant. All four now accept an optional filters: { organizationId?, projectId? } argument that is enforced on every adapter (inmemory, libsql, pg, mysql, mongodb, spanner):

  • On tenancy mismatch, get* returns null at the storage layer.
  • On tenancy mismatch, delete* is a silent no-op.
  • The tenancy predicate is folded into the destructive DML itself (scoped WHERE on the DELETE, an atomic gate + delete inside a transaction, or a scoped subquery for the results cascade). A concurrent tenant swap of the same id between a pre-check and the DELETE cannot let a scoped delete hit another tenant's row.

  Both behaviors match how a missing id already responds, so existence does not leak through error timing or messages.

  The same atomic-DML pattern is also applied to DatasetsStorage.deleteDataset across all 5 store adapters, closing a TOCTOU window between the pre-check and the parent DELETE that was introduced when tenancy filters were originally added.

  Dataset.getExperiment and the shared experiment-ownership gate on Dataset now forward the dataset's tenancy scope to storage, so experiment reads and downstream mutations (list results, update result, delete experiment) reached through a dataset handle are automatically scoped to the owning tenant.

  Legacy calls that omit filters are unchanged, so this is fully backwards-compatible.

  // Before: any caller who knew the id could read/delete across tenants.
  await store.experiments.getExperimentById({ id: experimentId });
  await store.experiments.deleteExperiment({ id: experimentId });
  
  // After: pass the caller's scope; wrong tenant gets null / silent no-op.
  await store.experiments.getExperimentById({
    id: experimentId,
    filters: { organizationId, projectId },
  });
  await store.experiments.deleteExperiment({
    id: experimentId,
    filters: { organizationId, projectId },
  });

• Fixed a cross-tenant data-access issue on datasets by scoping DatasetsManager.get and DatasetsManager.delete to tenancy filters. (#​18750)

  Previously get({ id }) and delete({ id }) looked up a dataset by its primary key alone. Any caller who knew a dataset id could read or delete it regardless of which organizationId / projectId it belonged to. This is now closed at the storage layer via a scoped SQL predicate (option (a) — no fetch-then-assert).

  What changed

  • DatasetsManager.get and DatasetsManager.delete accept optional organizationId and projectId.
  • The tenancy is stashed on the returned Dataset handle and forwarded to every downstream storage call (getDetails, update, addItem, item batch ops, startExperimentAsync).
  • The abstract storage contract (getDatasetById, deleteDataset) gained an optional filters?: DatasetTenancyFilters arg.
  • Item-mutation inputs (AddDatasetItemInput, UpdateDatasetItemInput, BatchInsertItemsInput, BatchDeleteItemsInput) and UpdateDatasetInput accept optional filters for the internal existence check.

  Behavior

  • Omitting tenancy preserves the existing behavior (no predicate added) — fully backwards compatible.
  • On tenancy mismatch, get throws NOT_FOUND (returns null at the storage layer) and delete is a silent no-op — matching how a missing id already behaves, so existence does not leak through error timing or messages.

  Example

  // Before
  const ds = await mastra.datasets.get({ id });
  await mastra.datasets.delete({ id });
  
  // After — scope to a tenant
  const ds = await mastra.datasets.get({ id, organizationId, projectId });
  await mastra.datasets.delete({ id, organizationId, projectId });

• Add optional batchId, datasetId, and datasetItemId fields to persisted scores so saved baseline scores can be grouped as one scoring pass and joined back to the dataset items they came from. (#​18331)

  • scoreTrace() accepts top-level batchId, datasetId, and datasetItemId when persisting a score for a stored trace.
  • ScoreRowData and score save payloads now include nullable batchId, datasetId, and datasetItemId.
  • Built-in stores with explicit score schema or attribute mappings now persist these provenance fields on saved scores.
  • D1, DSQL, MSSQL, and Upstash score stores now apply additive provenance migrations or deterministic score ordering for persisted score reads.

  await scoreTrace({
    storage,
    scorer,
    target: { traceId },
    batchId: 'baseline-batch-1',
    datasetId,
    datasetItemId,
  });

• Added optional organizationId and projectId fields to scores for multi-tenant isolation. Scores can now be saved with tenancy metadata and the listScoresBy* methods accept a filters option to scope results by organization and project. (#​18331)

  await storage.saveScore({ ...score, organizationId: 'org-a', projectId: 'proj-1' });
  
  const result = await storage.listScoresByScorerId({
    scorerId,
    filters: { organizationId: 'org-a', projectId: 'proj-1' },
  });

  projectId identifies the project scope, separate from resourceId which continues to mean the agent memory resource.

• Raise @mastra/core peer floor to >=1.49.0-0 on all storage adapters so the tenancy-related named exports the adapters now consume are guaranteed to exist at install time. (#​18861)

• Scoped getDatasetById and deleteDataset to tenancy filters when the caller passes organizationId / projectId. (#​18750)

  The adapters now push the tenancy predicate into the SQL/query when the new optional filters argument is present. Legacy calls that omit tenancy are unchanged. On mismatch, getDatasetById returns null and deleteDataset is a silent no-op — the cascade delete (dataset items and versions) is gated by a scoped parent pre-check, so cross-tenant data is never touched.

• Added optional organizationId and projectId query parameters to the dataset routes. (#​18750)

  GET /datasets/:datasetId, PATCH /datasets/:datasetId, and DELETE /datasets/:datasetId now accept optional tenancy query parameters. When provided, they are forwarded to mastra.datasets.get / .delete and the operation returns 404 if the dataset does not belong to the requested tenant. Requests that omit the query parameters keep their existing behavior.

  Example

  GET /datasets/abc123?organizationId=org_a&projectId=proj_1
  DELETE /datasets/abc123?organizationId=org_a
  

• Updated dependencies [700619b, 0f69865, 9250acd, 0c3d4bc, cc440a3, 6a61846, 215f9b0, 17369b2, c64c2a8, bcae929, ea6327b, 3439fa8, 85107f2, b33822e, 06e2680, 06ff9e0, d5c11e3, 7f5e1ff, ff80671, b8375c1, dab1257, 1240f05, 705ff39, e6fbd5b, 215f9b0, 24c10d3, 24c10d3, 24c10d3, 6f2026c, 24c10d3, 215f9b0, 215f9b0, 003f35d, f890eda, 1340fb7]:

  • @​mastra/core@​1.49.0

v1.14.3

Compare Source

Patch Changes

• Fixed buffered observation extraction metadata so stored OM chunks keep extracted values and extraction failures across memory storage adapters. (#​18655)

• Updated dependencies [b9a2961, b33c77d, 1274eb3, cdd5f93, 1274eb3, 0ac14ce, 9566d27, 8be63b0, 1009f77, 1b8728a, 23c31de, 0368766, 6f578ac, 345eecc, 1917c53, c01012f, 705ba98, 95857bc, e62c108, 2866f04, ee14cae, e84e791, c2f0b7f, 213feb8, 58e287b, e420b3c, be875ed, 9eefdc0, bfbbb01, 7d112ca]:

  • @​mastra/core@​1.48.0

v1.14.2

Compare Source

Patch Changes

• Fixed persistWorkflowSnapshot resetting a workflow run's createdAt on every re-persist. The default execution engine re-persists a run's snapshot on every step, so createdAt drifted to the last activity time and jumped forward on suspend/resume. Re-persisting now preserves the original createdAt and only advances updatedAt, so listWorkflowRuns ordering, fromDate/toDate filters, and the creation time shown in Studio stay correct. (#​18004)

• Updated dependencies [86623c1, 023766f, 0200e75, 7c9dd77, 7f9ae70, a0509c7, 06e0d63, bf3fe49, 01caf93, 438a971, 9990965, 77518cc, fbeda0c, 8a68844, bb2a13b, 24ceaea, a73cd1a, c0ffa3c, 462a769, 0504bf5, 0b5cc47, 87f38a3, d5fa3cd, fe98ef2, 6ccf67b, 793ea0f, 825d8de, 507a5c4, 5afe423, 307573b, 79b3626, c2c1d7b, 86623c1, 1505c07, f328049, e545228, 3eb852e, ffa09e7, 8c9f1c0, 461a7c5, 4211472, 9e45902, 5c0df77, e940f09]:

  • @​mastra/core@​1.47.0

v1.14.1

Compare Source

Patch Changes

• Added multi-tenant scoping columns (organizationId, projectId) to the experiments domain so experiment records and per-item results inherit the tenancy bucket of their parent dataset. (#​18388)

  Experiment, ExperimentResult, CreateExperimentInput, and AddExperimentResultInput now carry optional organizationId / projectId fields. ListExperimentsInput and ListExperimentResultsInput gain a filters: ExperimentTenancyFilters block (mirrors DatasetTenancyFilters) for scoping queries within a (organizationId, projectId) bucket. Tenancy is hydrated from the parent dataset on createExperiment and denormalized onto each ExperimentResult for efficient tenancy-scoped queries.

  The corresponding columns are also added to the mastra_experiments and mastra_experiment_results table schemas. Existing rows backfill to null, matching the rest of the dataset-tenancy surface.

  This release also clarifies the targetType contract via JSDoc:

  • CreateDatasetInput.targetType remains optional. Datasets without a TargetType are not experiment-eligible — the experiment runner requires a non-null CreateExperimentInput.targetType to resolve an executor.
  • Experiment.targetType / CreateExperimentInput.targetType stay required. An experiment by definition replays inputs against a specific target.

  No behavior change for existing OSS-created experiments; the new fields are additive and optional.

  Example:

  // Create an experiment scoped to a tenancy bucket. When the parent dataset
  // already carries `organizationId` / `projectId`, `runExperiment` hydrates
  // these fields automatically from the dataset record.
  const experiment = await storage.createExperiment({
    name: 'qa-regression',
    datasetId: 'ds_123',
    datasetVersion: 1,
    targetType: 'agent',
    targetId: 'agent_qa',
    totalItems: 10,
    organizationId: 'org_123',
    projectId: 'proj_123',
  });
  
  // List experiments within a tenancy bucket.
  const experiments = await storage.listExperiments({
    pagination: { page: 0, perPage: 20 },
    filters: { organizationId: 'org_123', projectId: 'proj_123' },
  });
  
  // List per-item results within the same bucket.
  const results = await storage.listExperimentResults({
    experimentId: experiment.id,
    pagination: { page: 0, perPage: 50 },
    filters: { organizationId: 'org_123', projectId: 'proj_123' },
  });

• Persist and filter dataset tenancy + candidate identity in storage adapters. (#​18314)

  createDataset now persists organizationId, projectId, candidateKey, and candidateId. listDatasets and listItems accept matching tenancy filters. Dataset items inherit organizationId / projectId from their parent dataset on insert, update, delete, and batch insert/delete — items are never settable per call (item tenancy follows dataset tenancy).

  All new columns are nullable and added retroactively via each adapter's existing column-migration path; no breaking DDL. Existing rows continue to read and write fine; new writes can choose to stamp tenancy.

  await storage.createDataset({
    name: 'candidates/missing-tool-call/incident-123',
    organizationId: 'org_abc',
    projectId: 'project_xyz',
    candidateKey: 'missing-tool-call',
    candidateId: 'incident-123',
  });
  
  await storage.listDatasets({
    pagination: { page: 0, perPage: 20 },
    filters: { organizationId: 'org_abc', projectId: 'project_xyz' },
  });

• Fixed: mastra build output no longer hangs on the first storage-touching request when an app uses LibSQLStore, PostgresStore, or MySQLStore with observational memory. mastra dev was unaffected; only the bundled mastra start output deadlocked. No code changes or bundler.externals workaround required on the app side after upgrading. (#​18302)

• Added storage for item-level tool mocks. Dataset items persist their toolMocks and experiment results persist their toolMockReport, so mocks and run diagnostics survive across sessions. (#​18036)

• Updated dependencies [5bd72d2, 1cc9ee1, 417baae, 65f255a, 74955f9, 30ebaf0, 5704634, 5c4e9a4, 4a88c6e, 417baae, 74955f9, 74955f9, 25961e3, 6a1428a, 87a17ef, e11ff30, 7794d71, 9d2c946, c0eda2b, 7b29f33, c0eda2b, b13925b, f1ec385, e14986f, 24912b1, bf94ec6, a29f371, 7686216, 74955f9, 073f910, 0be490f, 0be490f, ebbe1d3, 974f614, 3818814, 975c59a, 1f97ce5, 74955f9, 7f51548, 64f58c0, 74955f9, ebbe1d3, d95f394, 417baae, 8e25a78, 417baae, f3f0c9d, a5b22d3, 31be1cf, 417baae, 74955f9, 74955f9]:

  • @​mastra/core@​1.46.0

v1.14.0

Compare Source

Minor Changes

• Random bump (#​18178)

Patch Changes

• Updated dependencies [7c0d868, d9d2273, b04369d, 8f3c262]:
  • @​mastra/core@​1.45.0

v1.13.2

Compare Source

v1.13.0

Compare Source

Minor Changes

• Added LibSQL storage support for durable harness sessions. (#​17712)

  const storage = new LibSQLStore({ id: 'mastra-storage', url: 'file:./mastra.db' });
  
  const harness = new Harness({
    ownerId: 'my-app',
    agent,
    memory,
    storage,
    modes: [{ id: 'default', defaultModelId: '__GATEWAY_OPENAI_MODEL__' }],
    defaultModeId: 'default',
  });

• Add ThreadStateLibSQL, the LibSQL implementation of the new ThreadStateStorage domain. It persists per-thread, per-type state (e.g. the agent task list under type: "task") in the mastra_thread_state table, keyed by (threadId, type). Composing a LibSQL store wires this domain automatically, so an agent's task list now survives a process restart. (#​17820)

Patch Changes

• dependencies updates: (#​17148)

  • Updated dependency @libsql/client@^0.17.3 ↗︎ (from ^0.15.15, in dependencies)

• Fixed concurrent writes silently disappearing when using LibSQL with a local (file:) database. (#​16796)

  LibSQL backs a local database with a single connection. When one operation held an interactive write transaction (for example, persisting workflow snapshots) and another operation wrote at the same time (for example, creating a dataset experiment), the second write could be swept into the open transaction and rolled back — so it appeared to succeed but never persisted. This surfaced as concurrent agent/workflow runs losing unrelated records.

  Writes on a LibSQL client are now serialized, so a write issued during an in-flight transaction no longer interleaves with it.

• Updated dependencies [d468acb, 575f815, 34839c1, 053735a, 306909a, 5191af8, 43bd3d4, e6fa79e, 904bcdf, 7f5ee1d, 1e9aab5, 2bccba4, bf8eb6d, e9be4e7, 493a328, d53cfc2, 65799d4, c268c89, 34839c1, 014e00f, 029a414, d468acb, b147b29, d371ac1, 2bccba4, 0c72f03, cf182b7, 3b45ea9, a049c2a, f084be1, b147b29, 2a96528, f2ab060, 5d302c8, 34839c1, a952852, 2656d9c, 63e3fe1, 1d4ce8d, 8c68372]:

  • @​mastra/core@​1.42.0

v1.12.1

Compare Source

Patch Changes

• Added LibSQL support for the notifications storage domain so notification signals can persist thread-scoped inbox records. (#​17241)

  import { LibSQLStore } from '@​mastra/libsql';
  
  const storage = new LibSQLStore({ url: 'file:./mastra.db' });

• Fixed LibSQL memory cleanup so in-memory stores initialize their tables before clearing data. This prevents reset flows from failing with missing table errors such as mastra_resources. (#​17532)

• Updated dependencies [c973db4, 552285e, 77e686c, ece8dba, e751af2, e2a8380, be3f1cd, a34d9db]:

  • @​mastra/core@​1.39.0

v1.12.0

Compare Source

Minor Changes

• Added the tool_provider_connections storage domain. Stored agents can now persist per-agent ToolProvider config that round-trips on read/write/create. Runtime connection resolution (per-author, shared, caller-supplied) ships in a follow-up PR. (#​17247)

  What you can do

  • Pin a connection on a stored agent's config and have it round-trip on read/write/create.
  • Persist multiple connections per toolkit so a follow-up runtime PR can fan-out to the right one at execution time.

  Example

  import { LibSQLStore } from '@​mastra/libsql';
  
  const storage = new LibSQLStore({ url: process.env.DATABASE_URL });
  
  // Persist an OAuth connection that an agent can pin later
  await storage.toolProviders.upsertConnection({
    authorId: 'user-123',
    providerId: 'composio',
    connectionId: 'auth_abc',
    toolkit: 'gmail',
    label: 'Work inbox',
    scope: 'per-author',
  });
  
  // List a user's own connections (admin can omit authorId to list across users)
  const { items } = await storage.toolProviders.listConnectionsByAuthor({
    authorId: 'user-123',
    providerId: 'composio',
  });

  Additive — existing stored agents continue to work unchanged. The runtime that consumes this domain ships in a follow-up PR.

  PR 1 of 3 split from #​17224.

Patch Changes

• Added a public close() method to LibSQLStore that releases SQLite file handles and cleans up the WAL/shm sidecar files. Previously these handles stayed open until the process exited, which on Windows caused EBUSY errors when removing the storage directory after shutdown. Mastra.shutdown() now calls close() automatically, so you no longer need to reach into private fields. (#​17306)

  const storage = new LibSQLStore({ id: 'my-store', url: 'file:./dev.db' });
  
  // Release all file handles, including WAL/shm sidecar files
  await storage.close();
  
  // Now safe to remove the storage directory on all platforms, including Windows
  await fs.rm('./dev.db', { recursive: true, force: true });

• Updated dependencies [fa63872, d779de3, 1750c97, 9283971, f07b646, d8838ae, 40f9297, 19a8658, 850af77, 0f0d1ba, a18775a, 1baf2d1, 8c31bcd, 0e32507, 95b14cd, 07c3de7, 0bf2d93, 7b0d34c, a659a77, aa36be2, 3332be9, 212c635, d8838ae, 9aa5a73, f73c789, 8bd16da, c8630f8, 94dfef6, 47f71dc, 50ceae2, a122f79, 8cdde58, 3a081c1, 49f8abc, 847ff1e, 0c1ed1d, 259d409, 9e16c68, cefca33, d00e8c5, 36fa7e2, 87e9774, 65a72e7, fe9eacd, 4c02027, 0f77241, 849efb9, 92ff509, 3fce5e7, a763592, db79c86, 6855012, 80c7737, 7fef31c, 7fef31c, 3f1cf47]:

  • @​mastra/core@​1.38.0

v1.11.1

Compare Source

Patch Changes

• Fixed scheduler performance and correctness issues that could cause excessive Postgres CPU and noisy failed runs. (#​16805)

  • Added missing indexes on the schedules tables that the tick loop polls every 10 seconds: (status, next_fire_at) on mastra_schedules and (schedule_id, actual_fire_at) on mastra_schedule_triggers. Without these the scheduler performed a full sequential scan on every tick.
  • The scheduler tick loop is now only started when at least one workflow declares a schedule (or scheduler.enabled is set explicitly), so deployments without scheduled workflows no longer poll the database at all.
  • The scheduler now validates that a schedule's target workflow is still registered before firing it. Schedules whose target workflow has been removed from the Mastra config are skipped for a short grace window and then deleted, so stale rows stop producing failed workflow runs forever.
  • The scheduler is now lazily initialized inside startWorkers(). Accessing mastra.scheduler before startWorkers() runs throws a descriptive error instead of returning a half-initialized instance.

• Updated dependencies [452036a, c272d50, 27fd1b7, 5ba7253, 5556cc1, f73980d, 5499303, a702009, 9aee493, d8692af, 1a9cc60, 8cdb86c, 8534d79, [eda90c5](https://redirect.github.com/m

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.