@mastra/oracledb 0.4.0-alpha.0 → 0.4.1-alpha.0

package/dist/docs/SKILL.md

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

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.0-alpha.0",
+  "version": "0.4.1-alpha.0",
   "package": "@mastra/oracledb",
   "exports": {},
   "modules": {}

package/dist/docs/references/docs-memory-observational-memory.md

@@ -92,7 +92,9 @@ See [configuration options](https://mastra.ai/reference/memory/observational-mem
 
 > **Warning:** When you use OM with a client application, send **only the new message** from the client instead of the full conversation history.
 >
-> Observational memory still relies on stored conversation history. Sending the full history is redundant and can cause message ordering bugs when client-side timestamps conflict with stored timestamps.
+> Observational memory still relies on stored conversation history. Sending the full history is redundant and can cause message ordering bugs when client-side timestamps conflict with stored timestamps. Mastra filters client-echoed history before loading stored messages and uses the stored copy as the base when message IDs match, preserving stored timestamps and provider metadata while retaining new tool results.
+>
+> If you assemble the request input yourself and need it processed exactly as sent, set `retainFullInput: true` on `memory.options` for that call, or in the memory constructor options to apply it agent-wide. This disables that filtering. History still loads underneath. Every input message that isn't already stored is saved to the thread, including few-shot examples.
 >
 > For an AI SDK example, see [Using Mastra Memory](https://mastra.ai/integrations/agentic-ui/ai-sdk-ui).
 

package/dist/docs/references/reference-rag-vector-databases.md

@@ -54,6 +54,29 @@ const results = await store.hybridQuery({
 
 See the [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb) for details on `createSearchIndex()`, `textQuery()`, and `hybridQuery()`.
 
+### Automated Embedding
+
+MongoDB can generate the embeddings itself, so you don't need an embedding provider in your application. Create the index with `autoEmbed` and a Voyage AI model, write plain text, and search with a query string:
+
+```ts
+await store.createIndex({
+  indexName: 'myCollection',
+  autoEmbed: { model: 'voyage-4' },
+})
+await store.upsert({
+  indexName: 'myCollection',
+  documents: chunks.map(chunk => chunk.text),
+  metadata: chunks.map(chunk => ({ text: chunk.text })),
+})
+const results = await store.query({
+  indexName: 'myCollection',
+  queryText: 'search terms',
+  topK: 10,
+})
+```
+
+Automated Embedding is a MongoDB Preview feature and needs a deployment where it's available. See the [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb) for the supported options and requirements.
+
 **PgVector**:
 
 ```ts
@@ -345,6 +368,29 @@ await store.upsert({
 
 For detailed setup instructions and best practices, see the [official Elasticsearch documentation](https://www.elastic.co/docs/solutions/search/get-started).
 
+**Azure AI Search**:
+
+```ts
+import { AzureAISearchVector } from '@mastra/azure-ai-search'
+
+const store = new AzureAISearchVector({
+  id: 'azure-search-vectors',
+  endpoint: process.env.AZURE_AI_SEARCH_ENDPOINT!,
+  credential: process.env.AZURE_AI_SEARCH_CREDENTIAL!,
+})
+
+await store.createIndex({
+  indexName: 'my-collection',
+  dimension: 1536,
+})
+
+await store.upsert({
+  indexName: 'my-collection',
+  vectors: embeddings,
+  metadata: chunks.map(chunk => ({ text: chunk.text })),
+})
+```
+
 **Couchbase**:
 
 ```ts
@@ -626,6 +672,17 @@ Index names must:
 - Example: `myindex-` isn't valid (ends with hyphen)
 - Example: `MyIndex` isn't valid (contains uppercase letters)
 
+**Azure AI Search**:
+
+Index names must:
+
+- Use only lowercase letters, numbers, dashes (`-`), and underscore (`_`) characters
+- Not start or end with a dash
+- Be between 2 and 128 characters long
+- Example: `my-index-123` and `my_index` are valid
+- Example: `MyIndex` isn't valid (contains uppercase letters)
+- Example: `my-index-` isn't valid (ends with a dash)
+
 ### Upserting Embeddings
 
 After creating an index, you can store embeddings along with their basic metadata:

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

@@ -15,7 +15,7 @@ Storage adapters use the shared core retention contract for `prune()`, or a data
 | Adapter              | Mechanism               | Retention support                                                                                                                                                                      |
 | -------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | libSQL               | `prune()`               | All supported growth domains                                                                                                                                                           |
-| PostgreSQL           | `prune()`               | All supported growth domains. V-next observability drops expired partitions or chunks                                                                                                  |
+| PostgreSQL           | `prune()`               | All supported growth domains. vNext observability drops expired partitions or chunks                                                                                                   |
 | MongoDB              | `prune()` or native TTL | All supported growth domains. Native TTL indexes are also available                                                                                                                    |
 | DuckDB               | `prune()`               | Observability spans, metrics, logs, scores, and feedback                                                                                                                               |
 | MySQL                | `prune()`               | Observability spans                                                                                                                                                                    |
@@ -102,10 +102,10 @@ Each domain specifies its age-prunable tables and the timestamp column that anch
 | `memory`          | `resources`        | `createdAt`      | Resource age                                                     |
 | `threadState`     | `threadState`      | `updatedAt`      | Inactivity: state for still-active threads survives              |
 | `observability`   | `spans`            | `startedAt`      | Span age                                                         |
-| `observability`   | `metrics`          | `timestamp`      | Metric event age (v-next only)                                   |
-| `observability`   | `logs`             | `timestamp`      | Log event age (v-next only)                                      |
-| `observability`   | `scores`           | `timestamp`      | Score event age (v-next only)                                    |
-| `observability`   | `feedback`         | `timestamp`      | Feedback event age (v-next only)                                 |
+| `observability`   | `metrics`          | `timestamp`      | Metric event age (vNext only)                                    |
+| `observability`   | `logs`             | `timestamp`      | Log event age (vNext only)                                       |
+| `observability`   | `scores`           | `timestamp`      | Score event age (vNext only)                                     |
+| `observability`   | `feedback`         | `timestamp`      | Feedback event age (vNext only)                                  |
 | `scores`          | `scorers`          | `createdAt`      | Score record age                                                 |
 | `workflows`       | `workflowSnapshot` | `updatedAt`      | Inactivity, suspended or long-running workflows survive          |
 | `backgroundTasks` | `backgroundTasks`  | `completedAt`    | Time since completion, in-flight tasks (`NULL`) are never pruned |
@@ -122,7 +122,7 @@ Each domain specifies its age-prunable tables and the timestamp column that anch
 > - On PostgreSQL, timestamp anchors use the timezone-aware mirror columns (for example `createdAtZ`, `completedAtZ`).
 > - DuckDB observability stores append-only events for all five signals. Its `spans` policy uses the event `timestamp` column rather than `startedAt`.
 > - LibSQL and PostgreSQL support all domains above except `harness`, which PostgreSQL doesn't implement. MongoDB supports all except `threadState` and `harness`. DuckDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora DSQL, and Google Cloud Spanner currently support retention only in their `observability` domains, with the signal coverage shown in the support matrix.
-> - The v-next PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
+> - The vNext PostgreSQL observability domain stores signal events in day-partitioned tables (`spans`, `metrics`, `logs`, `scores`, `feedback`). For it, `prune()` drops whole day partitions (or TimescaleDB chunks) that are entirely older than the cutoff instead of deleting rows: effective level of detail is one day, and a partition is only dropped once its entire day is past `maxAge`. `PruneResult.deleted` reports the number of rows in the dropped partitions.
 
 ## Methods
 
@@ -208,7 +208,9 @@ You can also cancel a long-running prune with an `AbortSignal`: the loop stops b
 
 ClickHouse observability storage uses native table TTLs instead of `prune()`. Configure retention as days per signal. `init()` applies the TTLs to new and existing tables and skips `ALTER TABLE` statements when the configured TTL is already present.
 
-For deployments that need to update TTL configuration without running the full initialization path, call `applyRetention()` on the v-next observability store:
+Omitted signals, and signals set to zero or less, get no TTL. When you remove a signal from `retention`, the next `init()` or `applyRetention()` removes that table's TTL. If Mastra can't read the current TTLs from `system.tables`, it applies the configured TTLs and leaves the others unchanged.
+
+For deployments that need to update TTL configuration without running the full initialization path, call `applyRetention()` on the vNext observability store:
 
 ```typescript
 import { ObservabilityStorageClickhouseVNext } from '@mastra/clickhouse'

package/dist/index.cjs

@@ -6801,6 +6801,16 @@ var ObservabilityOracle = class ObservabilityOracle extends _mastra_core_storage
 		this.skipDefaultIndexes = config.skipDefaultIndexes;
 		this.indexes = filterIndexesForTables(config.indexes, ObservabilityOracle.MANAGED_TABLES);
 	}
+	getFeatures() {
+		return [
+			"logs",
+			"entity-type-discovery",
+			"entity-name-discovery",
+			"service-name-discovery",
+			"environment-discovery",
+			"tag-discovery"
+		];
+	}
 	async prune(policies, options) {
 		return (0, _mastra_core_storage.executeRetentionPrune)({
 			domain: "observability",