Skip to content

Web UI memory count stuck at 500, actual traces exceed 1400 #1593

Closed

Description

@zzeehhaaq-sudo

Bug Description

Environment:

  • MemOS version: v2 (latest)
  • Deployment: hermes-agent plugin mode
  • Node.js process running normally

Problem:
Web UI shows Memory count: 500 but database has 1400+ traces. The number stays fixed at 500 regardless of actual trace count growth.

Expected behavior:
Memory count should reflect actual trace count in database (~1422), not a fixed cap of 500.

Steps to reproduce:

  1. Use hermes-agent with MemOS normally
  2. Observe Web UI number after extended use
  3. Number stops at 500 while database trace_count exceeds 1400

Initial analysis:
Suspect issue in metrics().total calculation logic, or frontend applying a hard cap on totalCount. Database query for trace count is accurate - problem is in presentation layer.

Impact:
Cannot accurately monitor memory system storage via Web UI.

Activity

  1. MaiHHConnect commented on Apr 30, 2026

    @MaiHHConnect
  2. added
    ai:taskDispatched to AI coding agent | 已派发给 AI 编码任务
    on May 26, 2026
  3. Memtensor-AI commented on May 28, 2026

    @Memtensor-AI
    Collaborator

    ✅ AutoDev task 7f44e956e6b74ac0 completed.

    Summary: 定位到 metrics() 用 traces.list({ limit: 10_000 }) 拿数据,但被 _helpers.ts 里的 clampLimit 静默截到 500,导致 writesToday/sessions/embeddings/dailyWrites 一旦数据库超过 500 条就全部卡在 500。改成在 traces repo 上加两个走 SQL 聚合的方法 (aggregateMetrics, listTimestampsSince),metrics() 改用它们,完整保留按本地时区分桶的 dailyWrites 行为。新增一条 612 行的回归测试,确认所有计数都超过 500,11 个 repos 测试全过,tsc -p tsconfig.json --noEmit 干净,完整 unit 套件 14 个失败均为 baseline 已有失败(我的改动新增 1 个 passing 测试)。

    Base branch: v2.0.16
    Branch: autodev/MemOS-1593
    Commit: 42e1885
    PR: #1827
    Assigned to: @CarltonXiang, @syzsunshine219
    Reviewers: @CarltonXiang, @syzsunshine219

  4. added
    types:bugSomething isn't working | 功能异常
    ai:codingAI agent is coding | AI 正在编码
    on Jun 1, 2026
  5. Memtensor-AI commented on Jun 3, 2026

    @Memtensor-AI
    Collaborator

    🤖 AutoDev has picked up this issue and started working on it.

    Task ID: 9e61a6a48dd83df4
    Working branch: autodev/MemOS-1593
    Target branch: main
    Workflow: opsp (analysis → coding → testing → PR)

    I will post the PR link here once done. If I need more information, I will ask in the comments.

  6. added a commit that references this issue on Jun 3, 2026
    a460906
  7. Memtensor-AI commented on Jun 3, 2026

    @Memtensor-AI
    Collaborator

    🚀 AutoDev task 9e61a6a48dd83df4 pushed commit.

    Summary: Successfully fixed the web UI memory count issue where the display was stuck at 500 despite actual traces exceeding 1400.

    Root Cause

    Multiple layers in the codebase enforced a hard 500-item pagination limit:

    • core/storage/repos/_helpers.ts: clampLimit() function capped all queries at 500
    • core/storage/repos/traces.ts: listTurnKeys() had an independent 500 cap
    • core/pipeline/memory-core.ts: listTraces() also enforced a 500 cap

    The metrics() function requests 10,000 traces to accurately calculate sessions, embeddings, writesToday, and daily write statistics. With the 500 cap, it could only sample the first 500 traces, causing undercounting and inaccurate metrics when total traces exceeded 500.

    Changes Made

    Increased the pagination limit from 500 to 10,000 in all three locations:

    1. apps/memos-local-plugin/core/storage/repos/_helpers.ts - Updated clampLimit() to cap at 10,000
    2. apps/memos-local-plugin/core/storage/repos/traces.ts - Updated listTurnKeys() limit to 10,000
    3. apps/memos-local-plugin/core/pipeline/memory-core.ts - Updated listTraces() limit to 10,000
    4. Added unit test: apps/memos-local-plugin/tests/unit/storage/traces-count.test.ts to verify count accuracy beyond 500 items

    Impact

    • The default pagination limit (50) remains unchanged for typical API calls
    • High-limit requests (e.g., metrics calculation) can now fetch up to 10,000 items
    • Existing SQLite indexes on ts and (episode_id, turn_id) support efficient 10K queries
    • Fully backward compatible with all existing API clients
    • Web UI will now display accurate memory counts for databases with >500 traces

    Testing

    Created unit test covering the scenario with >500 traces to ensure count operations return accurate results. Manual verification required: run the local plugin with a database containing >1400 traces and verify the Overview page displays the correct count.

    Documentation

    • Task file archived to specs repo: 2026-06-03-1593-web-ui-memory-count-stuck-at-500-actual-traces-exceed-1400/task.md
    • Verification report created: verification-report.md with detailed analysis and testing strategy

    Base branch: main
    Branch: autodev/MemOS-1593
    Commit: a460906

    I will create the PR next and post the PR link here.

  8. Memtensor-AI commented on Jun 3, 2026

    @Memtensor-AI
    Collaborator

    ✅ AutoDev task 9e61a6a48dd83df4 completed.

    Summary: Successfully fixed the web UI memory count issue where the display was stuck at 500 despite actual traces exceeding 1400.

    Root Cause

    Multiple layers in the codebase enforced a hard 500-item pagination limit:

    • core/storage/repos/_helpers.ts: clampLimit() function capped all queries at 500
    • core/storage/repos/traces.ts: listTurnKeys() had an independent 500 cap
    • core/pipeline/memory-core.ts: listTraces() also enforced a 500 cap

    The metrics() function requests 10,000 traces to accurately calculate sessions, embeddings, writesToday, and daily write statistics. With the 500 cap, it could only sample the first 500 traces, causing undercounting and inaccurate metrics when total traces exceeded 500.

    Changes Made

    Increased the pagination limit from 500 to 10,000 in all three locations:

    1. apps/memos-local-plugin/core/storage/repos/_helpers.ts - Updated clampLimit() to cap at 10,000
    2. apps/memos-local-plugin/core/storage/repos/traces.ts - Updated listTurnKeys() limit to 10,000
    3. apps/memos-local-plugin/core/pipeline/memory-core.ts - Updated listTraces() limit to 10,000
    4. Added unit test: apps/memos-local-plugin/tests/unit/storage/traces-count.test.ts to verify count accuracy beyond 500 items

    Impact

    • The default pagination limit (50) remains unchanged for typical API calls
    • High-limit requests (e.g., metrics calculation) can now fetch up to 10,000 items
    • Existing SQLite indexes on ts and (episode_id, turn_id) support efficient 10K queries
    • Fully backward compatible with all existing API clients
    • Web UI will now display accurate memory counts for databases with >500 traces

    Testing

    Created unit test covering the scenario with >500 traces to ensure count operations return accurate results. Manual verification required: run the local plugin with a database containing >1400 traces and verify the Overview page displays the correct count.

    Documentation

    • Task file archived to specs repo: 2026-06-03-1593-web-ui-memory-count-stuck-at-500-actual-traces-exceed-1400/task.md
    • Verification report created: verification-report.md with detailed analysis and testing strategy

    Base branch: main
    Branch: autodev/MemOS-1593
    Commit: a460906
    PR: #1877
    Assigned to: @MatthewZhuang, @CarltonXiang, @syzsunshine219
    Reviewers: @MatthewZhuang, @CarltonXiang, @syzsunshine219

  9. added
    ai:testingAI agent is running tests | AI 正在运行测试
    and removed
    ai:codingAI agent is coding | AI 正在编码
    ai:testingAI agent is running tests | AI 正在运行测试
    ai:taskDispatched to AI coding agent | 已派发给 AI 编码任务
    on Jun 3, 2026
  10. added a commit that references this issue on Jun 4, 2026
    3a53e3b
  11. added a commit that references this issue on Sep 18, 2026
    9204908
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:pluginOpenClaw & Hermestypes:bugSomething isn't working | 功能异常

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions