fix(metrics): return real total memory count instead of capped page size

[Sanjays2402]

Summary

The Web UI memory-count card on the Memories page was stuck at 500 even when the database held 1400+ traces (#1593). The metrics path counted items from an already-limited listing instead of running a dedicated COUNT query.

Root cause

countTraces in apps/memos-local-plugin/core/pipeline/memory-core.ts computed the total by calling handle.repos.traces.list({ limit: 100_000 }) and reading rows.length. The shared helper buildPageClauses / clampLimit (in core/storage/repos/_helpers.ts) silently clamps every list limit to 500, so list({ limit: 100_000 }) actually returns at most 500 rows. The resulting rows.length (or grouped turnKeys.size) was therefore capped at 500 regardless of how many traces existed.

The /api/v1/traces endpoint uses countTraces, and the Memories view (web/src/views/MemoriesView.tsx) renders that response's total in its pagination footer, so the Web UI showed 500 forever.

Fix

In countTraces:

• For the no-search path, use the repo's dedicated SELECT COUNT(*) queries directly (repos.traces.count / countTurns). These don't go through buildPageClauses and have no 500-row cap, so the returned total reflects the real database size.
• For the substring-search path, page through traces explicitly with offset increments instead of relying on a single list() call (which would also be clamped at 500). Each batch is filtered for visibility and matched against the search needle, so the count stays accurate even above 500 rows.

Listings keep their existing page-size limits; only the count was wrong.

Verification

Added a regression test in tests/unit/pipeline/memory-core.test.ts that inserts 600 trace rows across 6 distinct turns and asserts:

• countTraces({}) returns 600 (was 500 before the fix)
• countTraces({ groupByTurn: true }) returns 6 (was capped at the smaller of 6 or 500 before; would break for >500 turns)

Files changed:

• apps/memos-local-plugin/core/pipeline/memory-core.ts (~34 net lines)
• apps/memos-local-plugin/tests/unit/pipeline/memory-core.test.ts (regression test)

Fixes #1593

[Copilot]

Pull request overview

Fixes an incorrect “total memories” count in the memos-local-plugin metrics path where totals were capped at 500 due to repo list pagination clamping, causing the Web UI Memories count to get stuck at 500 (issue #1593).

Changes:

• Updated countTraces to use repo-level COUNT queries when no substring search is provided, avoiding the list() 500-row cap.
• Updated substring-search counting to page through trace listings in batches so counts can exceed 500.
• Added a regression unit test that inserts 600 traces and validates both raw-trace and group-by-turn totals.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
apps/memos-local-plugin/core/pipeline/memory-core.ts	Fixes countTraces total counting logic to avoid the 500-row clamp (COUNT queries + explicit paging for search).
apps/memos-local-plugin/tests/unit/pipeline/memory-core.test.ts	Adds regression coverage ensuring totals are correct when trace rows exceed 500.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Sanjays2402]

Real catch — addressed in the latest commit. The new COUNT path was bypassing the visibility predicate that list() applies, so totals could include rows from other profiles/namespaces and break pagination math.

Fix: shared buildVisibilityClause helper used by both list() and the count methods, so the predicate stays authoritative in one place. countTraces in memory-core.ts now threads the relevant options through. Added a regression test that inserts traces under two profiles and asserts each profile's countTraces returns only its own count.