Skip to content

fix(deps): update dependency @mastra/memory to v1#51

Merged
batazor merged 1 commit into
mainfrom
renovate/mastra-memory-1.x
Mar 2, 2026
Merged

fix(deps): update dependency @mastra/memory to v1#51
batazor merged 1 commit into
mainfrom
renovate/mastra-memory-1.x

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Jan 21, 2026

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
@mastra/memory (source) ^0.14.0^1.0.0 age confidence

Release Notes

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

v1.5.2

Compare Source

Patch Changes
  • Fixed observational memory buffering to preserve more context and activate at the right time. (#​13476)

    • Fixed activation timing so observations trigger mid-step as soon as the threshold is crossed, instead of waiting for the next user message.
    • Fixed partial activations that left too much context — activation is now skipped when it can't compress enough, falling back to a full observation instead.
    • Fixed token counting so reasoning-only message parts no longer inflate totals and cause premature context reduction.
    • Clarified blockAfter behavior: values below 100 are treated as multipliers (e.g. 1.2 = 1.2× threshold), values ≥ 100 as absolute token counts.
  • Updated dependencies [df170fd, ae55343, c290cec, f03e794, aa4a5ae, de3f584, d3fb010, 702ee1c, f495051, e622f1d, 8d14a59, 861f111, 00f43e8, 1b6f651, 96a1702, cb9f921, 114e7c1, 1b6f651, 72df4a8]:

v1.5.1

Compare Source

Patch Changes
  • Fixed memory leak in Observational Memory (#​13425)

    Fixed several memory management issues that could cause OOM crashes in long-running processes with Observational Memory enabled:

    • Shared tokenizer: The default Tiktoken encoder (~80-120 MB heap) is now shared across all OM instances instead of being allocated per request. This is the primary fix — previously each request allocated two encoders that persisted in memory due to async buffering promise retention.
    • Cleanup key fix: Fixed a bug where reflection cycle IDs were not properly cleaned up due to using the wrong map key in cleanupStaticMaps.
  • Fixed PostgreSQL deadlock when parallel agents with different threadIds share the same resourceId while using Observational Memory. Thread scope now requires a valid threadId and throws a clear error if one is missing. Also fixed the database lock ordering in synchronous observation to prevent lock inversions. (#​13436)

  • Updated dependencies [24284ff, f5097cc, 71e237f, 13a291e, 397af5a, d4701f7, 2b40831, 6184727, 0c338b8, 6f6385b, 14aba61, dd9dd1c]:

v1.5.0

Compare Source

Minor Changes
  • Improved conversational continuity when the message window shrinks during Observational Memory activation. The agent now preserves its suggested next response and current task across activation, so it maintains context instead of losing track of the conversation. (#​13354)

    Also improved the Observer to capture user messages more faithfully, reduce repetitive observations, and treat the most recent user message as the highest-priority signal.

Patch Changes
  • Improved Observational Memory priority handling. User messages and task completions are now always treated as high priority, ensuring the observer captures the most relevant context during conversations. (#​13329)

  • Improved Observational Memory activation to preserve more usable context after activation. Previously, activation could leave the agent with too much or too little context depending on how chunks aligned with the retention target. (#​13305)

    • Activation now lands closer to the retention target by biasing chunk selection to slightly overshoot rather than undershoot
    • Added safeguards to prevent activation from consuming too much context (95% ceiling and 1000-token floor)
    • When pending tokens exceed blockAfter, activation now aggressively reduces context to unblock the conversation
    • bufferActivation now accepts absolute token values (>= 1000) in addition to ratios (0–1), giving more precise control over when activation triggers
  • Observations no longer inflate token counts from degenerate LLM output. Runaway or repetitive observer/reflector output is automatically detected and retried, preventing excessive context usage after activation. (#​13354)

  • Updated dependencies [0d9efb4, 7184d87, 5caa13d, 940163f, 47892c8, 45bb78b, 70eef84, d84e52d, 24b80af, 608e156, 2b2e157, 59d30b5, 453693b, 78d1c80, c204b63, 742a417]:

v1.4.0

Compare Source

Minor Changes
  • Update peer dependencies to match core package version bump (1.5.0) (#​13245)

  • Update peer dependencies to match core package version bump (1.4.1) (#​13151)

  • Update peer dependencies to match core package version bump (1.4.1) (#​13245)

  • Add instruction property to observational memory configs (#​13240)

    Adds optional instruction field to ObservationConfig and ReflectionConfig that allows users to extend the built-in observer/reflector system prompts with custom guidance.

    Example:

    const memory = new ObservationalMemory({
      model: openai('gpt-4'),
      observation: {
        instruction: 'Focus on user preferences about food and dietary restrictions.',
      },
      reflection: {
        instruction: 'Prioritize consolidating health-related observations together.',
      },
    });
Patch Changes
  • dependencies updates: (#​13167)

  • Added generic Harness class to @​mastra/core for orchestrating agents with modes, state management, built-in tools (ask_user, submit_plan), subagent support, Observational Memory integration, model discovery, and permission-aware tool approval. The Harness provides a reusable foundation for building agent-powered applications with features like thread management, heartbeat monitoring, and event-driven architecture. (#​13245)

    • Reflection retry logic now attempts compression up to level 3, so reflections more consistently shrink to meet token limits (#​13170)
    • Default target compression reduced from 50% to 25% (sliceTokenEstimate * 0.75), making automatic trimming less aggressive
    • tokensBuffered marker now reports the actual slice size rather than total observation tokens, giving accurate size monitoring

    These changes reduce failed reflections and make reported metrics match what is actually being processed.

  • Fixed a bug where the OM context window would jump to extremely high token counts (e.g. 16k → 114k) after observation activation. Two issues were causing this: (#​13070)

    • Token counter included OM metadata parts: data-om-activation marker parts (which contain the full observation text, up to 150k+ characters) were being counted as message tokens when loaded from the database. These parts are never sent to the LLM and are now skipped during token counting.
    • Marker duplication on messages: Activation markers were being added to assistant messages twice — once by the AI SDK stream and once by the persistence layer — doubling every marker and compounding the token inflation. Both persistMarkerToMessage and persistMarkerToStorage now deduplicate by type + cycleId before adding a marker.
  • Fixed thread title not being generated for pre-created threads. When threads were created before starting a conversation (e.g., for URL routing or storing metadata), the title stayed as a placeholder because the title generation condition checked whether the thread existed rather than whether it had a title. Threads created without an explicit title now get an empty title instead of a placeholder, and title generation fires whenever a thread has no title. Resolves #​13145. (#​13151)

  • Migrated MastraCode from the prototype harness to the generic CoreHarness from @​mastra/core. The createMastraCode function is now fully configurable with optional parameters for modes, subagents, storage, tools, and more. Removed the deprecated prototype harness implementation. (#​13245)

  • Fixed sub-agent memory context pollution that caused 'Exhausted all fallback models' errors when using Observational Memory with sub-agents. The parent agent's memory context is now preserved across sub-agent tool execution. (#​13051)

  • Updated dependencies [252580a, f8e819f, 5c75261, e27d832, e37ef84, 6fdd3d4, 10cf521, efdb682, 0dee7a0, 04c2c8e, 02dc07a, bb7262b, 1415bcd, cf1c6e7, 5ffadfe, 1e1339c, d03df73, 79b8f45, 9bbf08e, 0a25952, ffa5468, 3264a04, 6fdd3d4, 088d9ba, 74fbebd, aea6217, b6a855e, ae408ea, 17e942e, 2015cf9, 7ef454e, 2be1d99, 2708fa1, ba74aef, ba74aef, ec53e89, 9b5a8cb, 607e66b, a215d06, 6909c74, 192438f]:

v1.3.0

Compare Source

Minor Changes
  • @​mastra/opencode: Add opencode plugin for Observational Memory integration (#​12925)

    Added standalone observe() API that accepts external messages directly, so integrations can trigger observation without duplicating messages into Mastra's storage.

    New exports:

    • ObserveHooks — lifecycle callbacks (onObservationStart, onObservationEnd, onReflectionStart, onReflectionEnd) for hooking into observation/reflection cycles
    • OBSERVATION_CONTEXT_PROMPT — preamble that introduces the observations block
    • OBSERVATION_CONTEXT_INSTRUCTIONS — rules for interpreting observations (placed after the <observations> block)
    • OBSERVATION_CONTINUATION_HINT — behavioral guidance that prevents models from awkwardly acknowledging the memory system
    • getOrCreateRecord() — now public, allows eager record initialization before the first observation cycle
    import { ObservationalMemory } from '@&#8203;mastra/memory/processors';
    
    const om = new ObservationalMemory({ storage, model: 'google/gemini-2.5-flash' });
    
    // Eagerly initialize a record
    await om.getOrCreateRecord(threadId);
    
    // Pass messages directly with lifecycle hooks
    await om.observe({
      threadId,
      messages: myMessages,
      hooks: {
        onObservationStart: () => console.log('Observing...'),
        onObservationEnd: () => console.log('Done!'),
        onReflectionStart: () => console.log('Reflecting...'),
        onReflectionEnd: () => console.log('Reflected!'),
      },
    });

    Breaking: observe() now takes an object param instead of positional args. Update calls from observe(threadId, resourceId) to observe({ threadId, resourceId }).

Patch Changes
  • Fixed observational memory writing non-integer token counts to PostgreSQL, which caused invalid input syntax for type integer errors. Token counts are now correctly rounded to integers before all database writes. (#​12976)

  • Fixed cloneThread not copying working memory to the cloned thread. Thread-scoped working memory is now properly carried over when cloning, and resource-scoped working memory is copied when the clone uses a different resourceId. (#​12833)

  • Updated dependencies [7ef618f, b373564, 927c2af, b896b41, 6415277, 0831bbb, 63f7eda, a5b67a3, 877b02c, 7567222, af71458, eb36bd8, 3cbf121]:

v1.2.0

Compare Source

Minor Changes
  • Async buffering for observational memory is now enabled by default. Observations are pre-computed in the background as conversations grow — when the context window fills up, buffered observations activate instantly with no blocking LLM call. This keeps agents responsive during long conversations. (#​12939)

    Default settings:

    • observation.bufferTokens: 0.2 — buffer every 20% of messageTokens (~6k tokens with the default 30k threshold)
    • observation.bufferActivation: 0.8 — on activation, retain 20% of the message window
    • reflection.bufferActivation: 0.5 — start background reflection at 50% of the observation threshold

    Disabling async buffering:

    Set observation.bufferTokens: false to disable async buffering for both observations and reflections:

    const memory = new Memory({
      options: {
        observationalMemory: {
          model: 'google/gemini-2.5-flash',
          observation: {
            bufferTokens: false,
          },
        },
      },
    });

    Model is now required when passing an observational memory config object. Use observationalMemory: true for the default (google/gemini-2.5-flash), or set a model explicitly:

    // Uses default model (google/gemini-2.5-flash)
    observationalMemory: true
    
    // Explicit model
    observationalMemory: {
      model: "google/gemini-2.5-flash",
    }

    shareTokenBudget requires bufferTokens: false (temporary limitation). If you use shareTokenBudget: true, you must explicitly disable async buffering:

    observationalMemory: {
      model: "google/gemini-2.5-flash",
      shareTokenBudget: true,
      observation: { bufferTokens: false },
    }

    New streaming event: data-om-status replaces data-om-progress with a structured status object containing active window usage, buffered observation/reflection state, and projected activation impact.

    Buffering markers: New data-om-buffering-start, data-om-buffering-end, and data-om-buffering-failed streaming events for UI feedback during background operations.

Patch Changes

v1.1.0

Compare Source

Minor Changes
  • Added Observational Memory — a new memory system that keeps your agent's context window small while preserving long-term memory across conversations. (#​12599)

    Why: Long conversations cause context rot and waste tokens. Observational Memory compresses conversation history into observations (5–40x compression) and periodically condenses those into reflections. Your agent stays fast and focused, even after thousands of messages.

    Usage:

    import { Memory } from '@&#8203;mastra/memory';
    import { PostgresStore } from '@&#8203;mastra/pg';
    
    const memory = new Memory({
      storage: new PostgresStore({ connectionString: process.env.DATABASE_URL }),
      options: {
        observationalMemory: true,
      },
    });
    
    const agent = new Agent({
      name: 'my-agent',
      model: openai('gpt-4o'),
      memory,
    });

    What's new:

    • observationalMemory: true enables the three-tier memory system (recent messages → observations → reflections)
    • Thread-scoped (per-conversation) and resource-scoped (shared across all threads for a user) modes
    • Manual observe() API for triggering observation outside the normal agent loop
    • New OM storage methods for pg, libsql, and mongodb adapters (conditionally enabled)
    • Agent.findProcessor() method for looking up processors by ID
    • processorStates for persisting processor state across loop iterations
    • Abort signal propagation to processors
    • ProcessorStreamWriter for custom stream events from processors
  • Expose token usage from embedding operations (#​12556)

    • saveMessages now returns usage: { tokens: number } with aggregated token count from all embeddings
    • recall now returns usage: { tokens: number } from the vector search query embedding
    • Updated abstract method signatures in MastraMemory to include optional usage in return types

    This allows users to track embedding token usage when using the Memory class.

Patch Changes

v1.0.1

Compare Source

Patch Changes

v1.0.0

Compare Source

Major Changes
  • Refactor workflow and tool types to remove Zod-specific constraints (#​11814)

    Removed Zod-specific type constraints across all workflow implementations and tool types, replacing them with generic types. This ensures type consistency across default, evented, and inngest workflows while preparing for Zod v4 migration.

    Workflow Changes:

    • Removed z.ZodObject<any> and z.ZodType<any> constraints from all workflow generic types
    • Updated method signatures to use TInput and TState directly instead of z.infer<TInput> and z.infer<TState>
    • Aligned conditional types across all workflow implementations using TInput extends unknown pattern
    • Fixed TSteps generic to properly use TEngineType instead of any

    Tool Changes:

    • Removed Zod schema constraints from ToolExecutionContext and related interfaces
    • Simplified type parameters from TSuspendSchema extends ZodLikeSchema to TSuspend and TResume
    • Updated tool execution context types to use generic types

    Type Utilities:

    • Refactored type helpers to work with generic schemas instead of Zod-specific types
    • Updated type extraction utilities for better compatibility

    This change maintains backward compatibility while improving type consistency and preparing for Zod v4 support across all affected packages.

  • Remove getMessagesPaginated() and add perPage: false support (#​9670)

    Removes deprecated getMessagesPaginated() method. The listMessages() API and score handlers now support perPage: false to fetch all records without pagination limits.

    Storage changes:

    • StoragePagination.perPage type changed from number to number | false
    • All storage implementations support perPage: false:
      • Memory: listMessages()
      • Scores: listScoresBySpan(), listScoresByRunId(), listScoresByExecutionId()
    • HTTP query parser accepts "false" string (e.g., ?perPage=false)

    Memory changes:

    • memory.query() parameter type changed from StorageGetMessagesArg to StorageListMessagesInput
    • Uses flat parameters (page, perPage, include, filter, vectorSearchString) instead of selectBy object

    Stricter validation:

    • listMessages() requires non-empty, non-whitespace threadId (throws error instead of returning empty results)

    Migration:

    // Storage/Memory: Replace getMessagesPaginated with listMessages
    - storage.getMessagesPaginated({ threadId, selectBy: { pagination: { page: 0, perPage: 20 } } })
    + storage.listMessages({ threadId, page: 0, perPage: 20 })
    + storage.listMessages({ threadId, page: 0, perPage: false })  // Fetch all
    
    // Memory: Replace selectBy with flat parameters
    - memory.query({ threadId, selectBy: { last: 20, include: [...] } })
    + memory.query({ threadId, perPage: 20, include: [...] })
    
    // Client SDK
    - thread.getMessagesPaginated({ selectBy: { pagination: { page: 0 } } })
    + thread.listMessages({ page: 0, perPage: 20 })
  • Removed storage.getMessages() (#​9695)

    The getMessages() method has been removed from all storage implementations. Use listMessages() instead, which provides pagination support.

    Migration:

    // Before
    const messages = await storage.getMessages({ threadId: 'thread-1' });
    
    // After
    const result = await storage.listMessages({
      threadId: 'thread-1',
      page: 0,
      perPage: 50,
    });
    const messages = result.messages; // Access messages array
    console.log(result.total); // Total count
    console.log(result.hasMore); // Whether more pages exist

    Message ordering default

    listMessages() defaults to ASC (oldest first) ordering by createdAt, matching the previous getMessages() behavior.

    To use DESC ordering (newest first):

    const result = await storage.listMessages({
      threadId: 'thread-1',
      orderBy: { field: 'createdAt', direction: 'DESC' },
    });

    Renamed client.getThreadMessages()client.listThreadMessages()

    Migration:

    // Before
    const response = await client.getThreadMessages(threadId, { agentId });
    
    // After
    const response = await client.listThreadMessages(threadId, { agentId });

    The response format remains the same.

    Removed StorageGetMessagesArg type

    Use StorageListMessagesInput instead:

    // Before
    import type { StorageGetMessagesArg } from '@&#8203;mastra/core';
    
    // After
    import type { StorageListMessagesInput } from '@&#8203;mastra/core';
  • Bump minimum required Node.js version to 22.13.0 (#​9706)

  • Replace getThreadsByResourceIdPaginated with listThreadsByResourceId across memory handlers. Update client SDK to use listThreads() with offset/limit parameters instead of deprecated getMemoryThreads(). Consolidate /api/memory/threads routes to single paginated endpoint. (#​9508)

  • This simplifies the Memory API by removing the confusing rememberMessages method and renaming query to recall for better clarity. (#​9701)

    The rememberMessages method name implied it might persist data when it was actually just retrieving messages, same as query. Having two methods that did essentially the same thing was unnecessary.

    Before:

    // Two methods that did the same thing
    memory.rememberMessages({ threadId, resourceId, config, vectorMessageSearch });
    memory.query({ threadId, resourceId, perPage, vectorSearchString });

    After:

    // Single unified method with clear purpose
    memory.recall({ threadId, resourceId, perPage, vectorMessageSearch, threadConfig });

    All usages have been updated across the codebase including tests. The agent now calls recall directly with the appropriate parameters.

  • Rename RuntimeContext to RequestContext (#​9511)

  • Remove getThreadsByResourceId and getThreadsByResourceIdPaginated methods from storage interfaces in favor of listThreadsByResourceId. The new method uses offset/limit pagination and a nested orderBy object structure ({ field, direction }). (#​9536)

  • Remove various deprecated APIs from agent class. (#​9257)

    • agent.llmagent.getLLM()
    • agent.toolsagent.getTools()
    • agent.instructionsagent.getInstructions()
    • agent.speak()agent.voice.speak()
    • agent.getSpeakers()agent.voice.getSpeakers()
    • agent.listenagent.voice.listen()
    • agent.fetchMemory(await agent.getMemory()).query()
    • agent.toStep → Add agent directly to the step, workflows handle the transformation
  • Pagination APIs now use page/perPage instead of offset/limit (#​9592)

    All storage and memory pagination APIs have been updated to use page (0-indexed) and perPage instead of offset and limit, aligning with standard REST API patterns.

    Affected APIs:

    • Memory.listThreadsByResourceId()
    • Memory.listMessages()
    • Storage.listWorkflowRuns()

    Migration:

    // Before
    await memory.listThreadsByResourceId({
      resourceId: 'user-123',
      offset: 20,
      limit: 10,
    });
    
    // After
    await memory.listThreadsByResourceId({
      resourceId: 'user-123',
      page: 2, // page = Math.floor(offset / limit)
      perPage: 10,
    });
    
    // Before
    await memory.listMessages({
      threadId: 'thread-456',
      offset: 20,
      limit: 10,
    });
    
    // After
    await memory.listMessages({
      threadId: 'thread-456',
      page: 2,
      perPage: 10,
    });
    
    // Before
    await storage.listWorkflowRuns({
      workflowName: 'my-workflow',
      offset: 20,
      limit: 10,
    });
    
    // After
    await storage.listWorkflowRuns({
      workflowName: 'my-workflow',
      page: 2,
      perPage: 10,
    });

    Additional improvements:

    • Added validation for negative page values in all storage implementations
    • Improved perPage validation to handle edge cases (negative values, 0, false)
    • Added reusable query parser utilities for consistent validation in handlers
  • Changing getAgents -> listAgents, getTools -> listTools, getWorkflows -> listWorkflows (#​9495)

  • Mark as stable (83d5942)

  • Optimize default memory settings for semantic recall based on longmemeval data (#​9046)

    • Increased default topK from 2 to 4 for greater accuracy improvement
    • Lowered default messageRange from {before: 2, after: 2} to {before: 1, after: 1}
    • This provides ~8% accuracy gain while only increasing max messages from 10 to 12 (20% increase)
    • Updated documentation to reflect new defaults
    • Fixed playground UI to correctly display the new default values
    • These changes only affect users who enable semantic recall without specifying custom values
  • Enforcing id required on Processor primitive (#​9591)

  • Renamed MastraMessageV2 to MastraDBMessage (#​9255)
    Made the return format of all methods that return db messages consistent. It's always { messages: MastraDBMessage[] } now, and messages can be converted after that using @mastra/ai-sdk/ui's toAISdkV4/5Messages() function

Minor Changes
  • Update peer dependencies to match core package version bump (0.22.3) (#​9486)

  • Memory system now uses processors. Memory processors (MessageHistory, SemanticRecall, WorkingMemory) are now exported from @mastra/memory/processors and automatically added to the agent pipeline based on your memory config. Core processors (ToolCallFilter, TokenLimiter) remain in @mastra/core/processors. (#​9254)

  • Memory scope defaults changed from 'thread' to 'resource' (#​8983)

    Both workingMemory.scope and semanticRecall.scope now default to 'resource' instead of 'thread'. This means:

    • Working memory persists across all conversations for the same user/resource
    • Semantic recall searches across all threads for the same user/resource

    Migration: To maintain the previous thread-scoped behavior, explicitly set scope: 'thread':

    memory: new Memory({
      storage,
      workingMemory: {
        enabled: true,
        scope: 'thread', // Explicitly set for thread-scoped behavior
      },
      semanticRecall: {
        scope: 'thread', // Explicitly set for thread-scoped behavior
      },
    }),

    Also fixed issues where playground semantic recall search could show missing or incorrect results in certain cases.

  • Update peer dependencies to match core package version bump (1.0.0) (#​9495)

  • Update peer dependencies to match core package version bump (0.22.0) (#​8983)

  • Added new listThreads method for flexible thread filtering across all storage adapters. (#​11832)

    New Features

    • Filter threads by resourceId, metadata, or both (with AND logic for metadata key-value pairs)
    • All filter parameters are optional, allowing you to list all threads or filter as needed
    • Full pagination and sorting support

    Example Usage

    // List all threads
    const allThreads = await memory.listThreads({});
    
    // Filter by resourceId only
    const userThreads = await memory.listThreads({
      filter: { resourceId: 'user-123' },
    });
    
    // Filter by metadata only
    const supportThreads = await memory.listThreads({
      filter: { metadata: { category: 'support' } },
    });
    
    // Filter by both with pagination
    const filteredThreads = await memory.listThreads({
      filter: {
        resourceId: 'user-123',
        metadata: { priority: 'high', status: 'open' },
      },
      orderBy: { field: 'updatedAt', direction: 'DESC' },
      page: 0,
      perPage: 20,
    });

    Security Improvements

    • Added validation to prevent SQL injection via malicious metadata keys
    • Added pagination parameter validation to prevent integer overflow attacks
  • Schema-based working memory now uses merge semantics instead of replace semantics. (#​10659)

    Before: Each working memory update replaced the entire memory, causing data loss across conversation turns.

    After: For schema-based working memory:

    • Object fields are deep merged (existing fields preserved, only provided fields updated)
    • Set a field to null to delete it
    • Arrays are replaced entirely when provided

    Template-based (Markdown) working memory retains the existing replace semantics.

    This fixes issue #​7775 where users building profile-like schemas would lose information from previous turns.

Patch Changes
  • dependencies updates: (#​10133)

  • Add embedded documentation support for Mastra packages (#​11472)

    Mastra packages now include embedded documentation in the published npm package under dist/docs/. This enables coding agents and AI assistants to understand and use the framework by reading documentation directly from node_modules.

    Each package includes:

    • SKILL.md - Entry point explaining the package's purpose and capabilities
    • SOURCE_MAP.json - Machine-readable index mapping exports to types and implementation files
    • Topic folders - Conceptual documentation organized by feature area

    Documentation is driven by the packages frontmatter field in MDX files, which maps docs to their corresponding packages. CI validation ensures all docs include this field.

  • Fixed ReDoS vulnerability in working memory tag parsing. (#​11248)

    Replaced regex-based parsing with indexOf-based string parsing to prevent denial of service attacks from malicious input. The vulnerable regex /<working_memory>([^]*?)<\/working_memory>/g had O(n²) complexity on pathological inputs - the new implementation maintains O(n) linear time.

  • Embed AI types to fix peerdeps mismatches (9650cce)

  • Consolidate memory integration tests and fix working memory filtering in MessageHistory processor (#​11367)

    Moved extractWorkingMemoryTags, removeWorkingMemoryTags, and extractWorkingMemoryContent utilities from @mastra/memory to @mastra/core/memory so they can be used by the MessageHistory processor.

    Updated MessageHistory.filterMessagesForPersistence() to properly filter out updateWorkingMemory tool invocations and strip working memory tags from text content, fixing an issue where working memory tool call arguments were polluting saved message history for v5+ models.

    Also consolidated integration tests for agent-memory, working-memory, and pg-storage into shared test functions that can run against multiple model versions (v4, v5, v6).

  • Add new deleteVectors, updateVector by filter (#​10408)

  • Update peer dependencies to match core package version bump (1.0.0) ([#​9237](https://redirect.github.c


Configuration

📅 Schedule: 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.

@renovate renovate Bot force-pushed the renovate/mastra-memory-1.x branch from 638926d to f15d083 Compare January 22, 2026 07:20
@renovate renovate Bot force-pushed the renovate/mastra-memory-1.x branch 2 times, most recently from 440e95f to ede2d61 Compare February 4, 2026 22:05
@renovate renovate Bot force-pushed the renovate/mastra-memory-1.x branch 2 times, most recently from b3a84bb to 662b1cb Compare February 13, 2026 04:42
@renovate renovate Bot force-pushed the renovate/mastra-memory-1.x branch 3 times, most recently from 0c253ed to 07a62cf Compare February 24, 2026 19:06
@renovate renovate Bot force-pushed the renovate/mastra-memory-1.x branch from 07a62cf to 8ce6b06 Compare February 26, 2026 00:52
@batazor batazor merged commit 8df2653 into main Mar 2, 2026
2 checks passed
@renovate renovate Bot deleted the renovate/mastra-memory-1.x branch March 2, 2026 19:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant