memory: write side has no size caps, and every mutation rewrites the whole graph file — measured linear cost (hardening note)

Đang mở
  • Có gì không ổn?
#5,525 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, databases

Hướng nghiên cứu

Start with src/memory/index.ts, especially the write schemas at lines 889–903 and the load, save, and locking paths at lines 419, 442, and 532/610. Compare the existing read-side limits from issue #3953 and decide which write limits or README guidance fit this server. Done means the chosen limits or cost documentation address the uncapped growth and whole-file rewrite behavior described here.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement server-memory v2
Which server?

memory (@modelcontextprotocol/server-memory)

Protocol era

Modern (2026-07-28)

MCP client

No response

The problem

Summary
This is a scalability/hardening observation, not a security report and not a bug claim. In the memory server (src/memory/index.ts, checked at monorepo commit 6cfff622fb8eb41e2504340d5a6105d34094143c):

  • There is no cap on the write side: no length limit on entity/relation/observation strings, and no count limit on the per-call input arrays or on the total graph. The only .max( in the file is the 2048-character cap on the search query string (index.ts:905, 909); the schemas at index.ts:889-903 carry no limits.
  • Every mutation loads and validates the entire file and writes the entire graph back (temp file + rename), under the cross-process file lock: load at index.ts:442, save at index.ts:532, 610, locking at index.ts:419.
    The read side already gained opt-in limits (#3953: observationLimit, limit, …), so the write side is the remaining uncapped direction.

Measured cost (real KnowledgeGraphManager, synthetic dummy graph)
Median of 3 runs, single process, one minimal mutation ("add one entity") per measurement; synthetic entities ≈240 bytes/line with 3 observations each:
| Entities | File size | Time to add 1 entity |
| 1,000 | 0.23 MB | 7 ms |
| 5,000 | 1.18 MB | 25 ms |
| 20,000 | 4.78 MB | 93 ms |
| 50,000 | 12.0 MB | 223 ms |
| 100,000 | 24.1 MB | 411 ms |
The cost is linear at ≈4.1 µs/entity, and the write volume is the whole file every time: at 100,000 entities, adding a single ~300-byte entity rewrote 24.06 MB. (Measurement harness and raw numbers are preserved on the reporter's side and can be shared verbatim.)

What this note does not claim
No availability or timeout claim is made. At the measured rate, a single mutation costs well under a second even at 100,000 entities; nothing here demonstrates a client being starved or a write timing out. The point is only the combination of (a) no operator-set ceiling on how large the store can grow through the write tools, and (b) a per-mutation cost and lock-holding time that grow linearly with that unbounded size, in the shared-file multi-client configuration the README supports.

Reporter: Tomoki Murota, CISSP

Solution you have in mind (optional)

Consider parity with the read side: opt-in caps for write payloads and/or total graph size (entities, relations, observation bytes), and/or a short README note documenting the linear per-mutation cost so operators sharing one file can size it deliberately.

Which MCP feature does it demonstrate? (optional)

No response

Alternatives or workarounds you have tried

No response

Already built it locally?

Not built. No diff is attached, per this repository's contribution model. The measurement harness and raw numbers are preserved on the reporter's side and can be shared verbatim.

Before you submit
  • I searched existing issues and this is not a duplicate.
  • This is a request for this repository or one of its servers, not a new server, the MCP specification or an SDK.
Ngôn ngữ chính
TypeScript
Star
91.9k
Fork
11.9k
Merge trung bình
3 giờ 10 phút
Pull request đã merge (30 ngày)
178

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/servers

Tất cả issue của modelcontextprotocol/servers

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.