[ShauryaaSharma]

Linked Issue

Closes #6101

Description

Memory.add()'s LLM extraction step in the TypeScript OSS SDK caught all errors from generateResponse , including provider/transport failures (rate limits, timeouts, connection errors) and swallowed them
by returning []. This made "the LLM is unreachable" indistinguishable from "the LLM ran and extracted nothing," and callers had no way to detect or retry the former.

This mirrors the Python SDK bug already fixed by #5878 (tracked in #5903, which explicitly flagged this TS-side follow-up).

Before (mem0-ts/src/oss/src/memory/index.ts:855-858):

} catch (e) {
  console.error("LLM extraction failed:", e);
  return [];
}

After:

} catch (e) {
  console.error("LLM extraction failed:", e);
  throw new LLMError(`LLM extraction failed: ${e}`, { cause: e });
}

Adds a typed LLMError class (alongside the existing error-handling patterns in this file) so callers can distinguish a transport failure from a genuinely empty/invalid LLM response. The downstream JSON-parse failure path is untouched and still returns [], since that case really is "no facts extracted," not a transport error.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Refactor (no functional changes)
• Documentation update

Breaking Changes

N/A

Test Coverage

• I added/updated unit tests
• I added/updated integration tests
• I tested manually (describe below)
• No tests needed (explain why)

Added mem0-ts/src/oss/tests/memory.llm-error.test.ts with two regression tests mirroring the Python regression test added in #5878 (test_llm_extraction_exception_is_reraised):

• add() rejects with LLMError instead of resolving with an empty result
• the thrown LLMError preserves the original error as .cause

PASS src/oss/tests/memory.llm-error.test.ts
  Memory - LLM extraction transport failures
    ✓ add() rejects with LLMError instead of returning an empty result
    ✓ thrown LLMError preserves the original error as its cause

Also ran the full related suite with zero regressions (memory.add, memory.validation, memory.crud, memory.init,
memory.entity-boost — 80/80 passing), the full OSS suite (580/623 passing, the 43 failures are pre-existing Windows EPERM temp-dir issues in unrelated sqlite/vector-store tests, verified identical on unmodified main), tsc --noEmit (no new errors), and a tsup build (confirmed LLMError is correctly exported from the public dist/oss/index.d.ts surface).

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have added tests that prove my fix/feature works
• New and existing tests pass locally
• I have updated documentation if needed

[ShauryaaSharma]

Hey @kartik-mem0
This closes the TS-side follow-up explicitly flagged in #5903 (Python side already fixed via #5878).

Summary of the change and verification is in the PR description. A couple of notes for review:

• LLMError is a small standalone class local to mem0-ts/src/oss/src/memory/index.ts : the OSS package doesn't share the MemoryError hierarchy from mem0-ts/src/common/exceptions.ts (that's client-package-only), so I didn't reuse it.
• Kept the existing console.error log line before the throw, matching the Python fix's pattern of logging + re-raising.

Happy to adjust the error shape/naming if you'd prefer something different. Let me know if anything else is needed!