feat(memory): integrate mem0 long-term memory for Chat Shell #295

Micro66 · 2025-12-04T14:03:25Z

Summary

Integrate mem0 long-term memory service for Chat Shell type conversations
Add memory management API endpoints for CRUD operations on user memories
Add frontend Memory Panel component for viewing and managing memories in chat interface

Changes

Backend

New: backend/app/services/chat/memory_service.py - Service for mem0 API integration
New: backend/app/api/endpoints/memory.py - REST API endpoints for memory management
Modified: backend/app/core/config.py - Add MEM0_BASE_URL, MEM0_API_KEY, MEM0_ENABLED config
Modified: backend/app/services/chat/chat_service.py - Retrieve memories before chat, save after completion
Modified: backend/app/api/api.py - Register memory router

Frontend

New: frontend/src/apis/memory.ts - API client for memory management
New: frontend/src/features/tasks/components/MemoryPanel.tsx - Sidebar panel for managing memories
Modified: frontend/src/features/tasks/components/ChatArea.tsx - Add memory button and panel integration

Architecture

The mem0 long-term memory complements the existing Redis short-term session memory:

Redis (SessionManager): Task-level session history with TTL expiration
mem0 (MemoryService): User-level cross-session memories for preferences and facts

Configuration

MEM0_BASE_URL=http://localhost:8080
MEM0_API_KEY=your-api-key-if-needed
MEM0_ENABLED=true

Test plan

Verify chat functionality works normally when mem0 is not configured (graceful degradation)
Verify memories are retrieved and injected into chat context when mem0 is configured
Verify memories are saved after successful chat completion
Test memory panel UI: list, search, edit, delete operations
Verify memory API endpoints return correct responses

Summary by CodeRabbit

Release Notes

New Features
- Long-term memory management now available in chat with capabilities to search, view, edit, and delete stored conversation memories
- New Memory Panel interface for managing memories with inline editing, keyword-based search, and manual refresh options
- Memory service health status check to validate system configuration and availability

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Add mem0 long-term memory integration for Chat Shell type conversations, enabling user-level cross-session memory that complements the existing Redis short-term session management. Backend changes: - Add memory_service.py for mem0 API integration (add, search, update, delete) - Add MEM0_BASE_URL, MEM0_API_KEY, MEM0_ENABLED config options - Modify chat_service.py to retrieve memories before chat and save after - Create /api/memories endpoints for memory management (CRUD operations) Frontend changes: - Add memory.ts API client for memory management - Add MemoryPanel component as sidebar for viewing/editing memories - Integrate memory button in ChatArea header The system gracefully degrades when mem0 is not configured, ensuring normal chat functionality without long-term memory features.

coderabbitai · 2025-12-04T14:03:46Z

Walkthrough

This PR integrates long-term memory capabilities into the chat application via a new mem0-backed memory service. It adds memory CRUD endpoints, extends the chat stream with user context and memory injection, introduces configuration settings for mem0 integration, and includes a frontend memory management panel component.

Changes

Cohort / File(s)	Summary
Configuration & Service Exports `backend/app/core/config.py`, `backend/app/services/chat/__init__.py`	Added MEM0_BASE_URL, MEM0_API_KEY, and MEM0_ENABLED settings; re-exported memory_service from chat package for public API access.
Memory Service Implementation `backend/app/services/chat/memory_service.py`	New MemoryService class with async CRUD operations, health checks, and formatting utilities for interacting with self-hosted mem0 backend. Includes lazy-initialized httpx client with Bearer token auth and 30s timeout.
Chat Stream Integration `backend/app/api/endpoints/adapter/chat.py`, `backend/app/services/chat/chat_service.py`	Added user_id parameter to chat_stream; integrated memory retrieval before LLM call and asynchronous memory saving after completion. Memory context injected into message building; _build_messages extended to accept and combine memory_context.
Memory Management API `backend/app/api/api.py`, `backend/app/api/endpoints/memory.py`	New memory endpoint module with GET/PUT/DELETE operations, health check, and keyword search. Registered router with /memories prefix. Added data models (MemoryResponse, MemoryListResponse, UpdateMemoryRequest) with ownership enforcement.
Frontend API Client `frontend/src/apis/memory.ts`	New TypeScript client for memory API with getMemories, getMemory, updateMemory, deleteMemory, and checkMemoryHealth functions; includes bearer token auth and error handling.
Frontend UI Components `frontend/src/features/tasks/components/ChatArea.tsx`, `frontend/src/features/tasks/components/MemoryPanel.tsx`	Added MemoryPanel toggle button to ChatArea; new MemoryPanel component with searchable memory list, inline edit/delete, health status check, and toast notifications.

Sequence Diagram

sequenceDiagram
    participant User as User/Client
    participant Chat as Chat Endpoint
    participant ChatSvc as Chat Service
    participant MemSvc as Memory Service
    participant mem0 as mem0 Backend
    participant LLM as LLM Provider

    User->>Chat: POST /chat with message + user_id
    Chat->>ChatSvc: chat_stream(user_id, message)
    
    rect rgb(200, 220, 255)
    Note over ChatSvc,mem0: Memory Retrieval Phase
    ChatSvc->>MemSvc: search_memories(user_id, query)
    MemSvc->>mem0: GET /v1/memories/search/
    mem0-->>MemSvc: [memories]
    MemSvc-->>ChatSvc: formatted memory context
    end
    
    rect rgb(220, 255, 220)
    Note over ChatSvc,LLM: Chat Generation Phase
    ChatSvc->>ChatSvc: _build_messages(history, message, memory_context)
    ChatSvc->>LLM: stream completion with messages
    LLM-->>ChatSvc: streamed response chunks
    ChatSvc-->>Chat: StreamingResponse
    Chat-->>User: streaming chunks
    end
    
    rect rgb(255, 230, 200)
    Note over ChatSvc,mem0: Memory Save Phase (async)
    ChatSvc->>MemSvc: add_memory(user_id, messages) [async, fire-and-forget]
    MemSvc->>mem0: POST /v1/memories/ with conversation
    mem0-->>MemSvc: memory saved
    end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Memory service async operations & error handling – Verify httpx client lifecycle, timeout logic, graceful fallbacks on mem0 unavailability
Chat service memory context integration – Confirm memory retrieval doesn't block streaming, async save doesn't break response flow, parameter passing is consistent
Frontend component state & API interactions – Check memory panel search/edit/delete state flows, error handling and toast notifications, authorization headers

Possibly related PRs

feat(chat): 支持单模型组成team实现聊天 #268 – Modifies the streaming chat endpoint and chat_service integration; both PRs add parameters to the same chat_stream call path.
支持流式消息的恢复 #291 – Changes to backend/app/api/endpoints/adapter/chat.py and chat_service.py streaming logic; related to chat state management during streaming.

Suggested reviewers

qdaxb
feifei325

Poem

🐰 Memory's magic, long held true,
Whispers of chats we once knew,
Brain-shaped buttons, panels bright,
Conversations recall'd just right!
The rabbit hops through mem0's door, 🧠✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically summarizes the main change: integrating mem0 long-term memory into Chat Shell, matching the core objective of the PR.
Docstring Coverage	✅ Passed	Docstring coverage is 86.21% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

📝 Generate docstrings

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch weagent/feature-mem0-long-term-memory

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

coderabbitai

Actionable comments posted: 7

🧹 Nitpick comments (8)

frontend/src/features/tasks/components/ChatArea.tsx (1)
1148-1151: Consider adding memory button to the floating input area for consistency.

The memory panel button (Brain icon) is only present in the initial input area (no messages view) at Lines 926-935, but not in the floating input area when hasMessages is true. Users viewing an existing conversation cannot access the memory panel.

Consider adding the memory button here for feature parity:
                   <div className="ml-auto flex items-center gap-2 flex-shrink-0">
+                    {/* Memory Panel Button */}
+                    <Button
+                      variant="ghost"
+                      size="icon"
+                      onClick={() => setIsMemoryPanelOpen(true)}
+                      className="h-6 w-6 rounded-full flex-shrink-0 translate-y-0.5"
+                      title="View memories"
+                    >
+                      <Brain className="h-4 w-4 text-text-secondary" />
+                    </Button>
                     {!shouldHideQuotaUsage && (
frontend/src/features/tasks/components/MemoryPanel.tsx (2)

142-165: Consider replacing confirm() with a custom confirmation dialog.

The native confirm() dialog works but provides a basic browser-native experience that may feel inconsistent with the rest of the UI. Consider using an AlertDialog from shadcn/ui for better UX consistency.

184-195: Panel accessibility: consider adding keyboard trap and focus management.

The fixed positioning panel overlays content but doesn't trap keyboard focus. Users navigating with keyboard can tab out of the panel to elements behind it. Consider:

Adding aria-modal="true" and role="dialog"

Trapping focus within the panel when open

Returning focus to the trigger button on close

This is an accessibility enhancement that could be addressed in a follow-up.
backend/app/services/chat/memory_service.py (2)
12-14: Remove unused import.

The datetime import on line 13 is not used anywhere in this file.
 import logging
-from datetime import datetime
 from typing import Any, Dict, List, Optional
42-62: Consider adding client lifecycle management for application shutdown.

The close() method exists but there's no automatic cleanup mechanism. If the application shuts down without explicitly calling close(), the HTTP client connection pool may not be properly released.

Consider registering this with FastAPI's lifespan context or implementing __aenter__/__aexit__ for async context manager support, though this is a minor concern since httpx handles cleanup reasonably well on garbage collection.
backend/app/api/endpoints/memory.py (2)
71-71: Extract magic number to a named constant.

The hard-coded limit 100 should be extracted to a module-level constant for maintainability.

Apply this diff:
+# Maximum number of memories to return in search results
+MAX_SEARCH_RESULTS = 100
+
 @router.get("")
 async def get_memories(
     keyword: Optional[str] = None,
     current_user: User = Depends(security.get_current_user),
 ) -> MemoryListResponse:
     """
     Get all memories for the current user.

     Args:
         keyword: Optional keyword to search/filter memories

     Returns:
         List of user's memories
     """
     if not memory_service.is_configured:
         return MemoryListResponse(memories=[], total=0)

     try:
         if keyword:
             # Search memories by keyword
             raw_memories = await memory_service.search_memories(
                 user_id=current_user.id,
                 query=keyword,
-                limit=100,
+                limit=MAX_SEARCH_RESULTS,
             )
As per coding guidelines, magic numbers must be extracted to named constants.

82-93: Extract duplicate memory transformation logic to a helper function.

The memory transformation logic (extracting id, content, created_at, updated_at from raw memory dictionaries) is duplicated across multiple endpoints (lines 82-93, 130-132, 184-191).

Extract this logic into a helper function:
def _normalize_memory_response(mem: dict[str, Any], memory_id: Optional[str] = None) -> Optional[MemoryResponse]:
    """
    Normalize a raw memory dict to MemoryResponse.
    
    Args:
        mem: Raw memory dictionary from mem0
        memory_id: Optional override for memory ID
        
    Returns:
        MemoryResponse if valid, None otherwise
    """
    if not mem:
        return None
        
    mem_id = memory_id or mem.get("id", mem.get("memory_id", ""))
    content = mem.get("memory", mem.get("text", mem.get("content", "")))
    created_at = mem.get("created_at", mem.get("createdAt"))
    updated_at = mem.get("updated_at", mem.get("updatedAt"))
    
    if not mem_id or not content:
        return None
        
    return MemoryResponse(
        id=str(mem_id),
        content=content,
        created_at=str(created_at) if created_at else None,
        updated_at=str(updated_at) if updated_at else None,
    )
Then use it in endpoints:
# In get_memories:
memories = [
    normalized 
    for mem in raw_memories 
    if (normalized := _normalize_memory_response(mem))
]

# In get_memory:
return _normalize_memory_response(mem, memory_id)

# In update_memory:
return _normalize_memory_response(result, memory_id)
This follows the DRY principle and improves maintainability.
frontend/src/apis/memory.ts (1)
64-76: Extract duplicate error handling logic to a helper function.

The error parsing logic (extracting detail from JSON or falling back to raw text) is duplicated across all four API functions (lines 64-76, 98-110, 134-146, 168-180).

Extract to a helper function:
/**
 * Parse error response and extract error message.
 * 
 * @param response - Failed fetch response
 * @returns Error message string
 */
async function parseErrorResponse(response: Response): Promise<string> {
  const errorText = await response.text()
  let errorMsg = errorText
  try {
    const json = JSON.parse(errorText)
    if (json && typeof json.detail === 'string') {
      errorMsg = json.detail
    }
  } catch {
    // Not JSON, use raw text
  }
  return errorMsg
}
Then simplify each function:
if (!response.ok) {
  const errorMsg = await parseErrorResponse(response)
  throw new Error(errorMsg)
}
This eliminates significant code duplication and follows the DRY principle.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aed20b9 and 0bf01d4.

📒 Files selected for processing (10)

backend/app/api/api.py (2 hunks)
backend/app/api/endpoints/adapter/chat.py (1 hunks)
backend/app/api/endpoints/memory.py (1 hunks)
backend/app/core/config.py (1 hunks)
backend/app/services/chat/__init__.py (1 hunks)
backend/app/services/chat/chat_service.py (7 hunks)
backend/app/services/chat/memory_service.py (1 hunks)
frontend/src/apis/memory.ts (1 hunks)
frontend/src/features/tasks/components/ChatArea.tsx (5 hunks)
frontend/src/features/tasks/components/MemoryPanel.tsx (1 hunks)

🧰 Additional context used

📓 Path-based instructions (9)

**/*.{py,ts,tsx,js,jsx}