mastra-ai/mastra · error

Observational memory is not enabled

Error message

Observational memory is not enabled

What it means

This is thrown by Memory methods that delegate to the observational-memory engine (e.g. updateRecordConfig). The OM engine is only instantiated when observational memory is enabled in the Memory options; when it is absent, the method cannot run and the library throws.

Source

Thrown at packages/memory/src/index.ts:2379

   *   config: {
   *     observation: { messageTokens: 2000 },
   *     reflection: { observationTokens: 8000 },
   *   },
   * });
   * ```
   */
  public async updateObservationalMemoryConfig({
    threadId,
    resourceId,
    config,
  }: {
    threadId: string;
    resourceId?: string;
    config: Record<string, unknown>;
  }): Promise<void> {
    const omEngine = await this.omEngine;
    if (!omEngine) {
      throw new Error('Observational memory is not enabled');
    }
    await omEngine.updateRecordConfig(threadId, resourceId, config);
  }

  /**
   * Summarize one of this memory's threads in one shot.
   *
   * Loads the thread's messages from storage and runs `summarizeConversation()` over them —
   * Observational Memory's Observer plumbing as a standalone call. Nothing is written back to
   * memory: the summary and extracted values are returned to you (and to each extractor's
   * `onExtracted` hook), so you decide where they go. Works whether or not observational
   * memory is enabled on this instance.
   *
   * Use this when a session ends and you want a summary or structured extraction of the whole
   * conversation — for example a voice call at hang-up.
   *
   * Messages are loaded page-by-page starting from the newest, bounded by `lastMessages` and
   * `maxInputTokens`, so summarizing a very long thread doesn't read its entire history from

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Enable observational memory in the Memory options (e.g. options.enableObservationalMemory = true, or supply the OM configuration object)
  2. Guard the call site: only invoke OM management methods when OM is known to be enabled
  3. Check for a runtime/config flag or env var that conditionally disables OM and reconcile it with the code path

Example fix

// before
const memory = new Memory({ storage, vector, embedder });
await memory.updateRecordConfig({ threadId, resourceId, config });

// after
const memory = new Memory({ storage, vector, embedder, enableObservationalMemory: true });
await memory.updateRecordConfig({ threadId, resourceId, config });
Defensive patterns

Strategy: validation

Validate before calling

function omEnabled(memory: Memory): boolean {
  return Boolean((memory as any).omEngine ?? (memory as any).options?.enableObservationalMemory);
}
if (!omEnabled(memory)) return; // skip OM-specific management call

Try / catch

try {
  await memory.updateRecordConfig({ threadId, resourceId, config });
} catch (err) {
  if (err instanceof Error && err.message === 'Observational memory is not enabled') {
    console.warn('Skipping record config update: OM disabled');
    return;
  }
  throw err;
}

Prevention

When it happens

Trigger: Calling memory.updateRecordConfig(...) (or similar OM-specific methods) on a Memory instance whose options do not enable observational memory, so `omEngine` resolves to undefined.

Common situations: Copy-pasting OM management code into a project whose Memory is configured with plain storage/vector only; toggling OM off via config but keeping the updateRecordConfig calls; assuming OM ships enabled by default.

Related errors


AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/bacf1c8ce930572c. Report an issue: GitHub.