logs_2.sqlite: rmcp::service TRACE rows (~1.3 MB ListToolsResult dumps) bypass the noisy-target filter — 50-68 MB/day with a large MCP catalog

Open
#34,291 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
rust, sqlite

Research direction

Start by reading the persistent-log noisy-target filter introduced in #29457 and tracing the sqlite sink that writes logs_2.sqlite. Reproduce the behavior with read-only queries and the rmcp::service TRACE rows, then verify that the target is filtered or per-row payloads are capped without the large ListToolsResult dumps continuing to accumulate.

Written by the indexing model from the issue text.

Description

app-server bug CLI mcp performance
What happened

After the #28224 fixes landed (#29432, #29457, #29599 — big improvement, thank you), one high-volume emitter still reaches the persistent sqlite feedback log (logs_2.sqlite): target rmcp::service, level TRACE, whose bodies are full JSON-RPC PeerMessage dumps from app_server.request{...}:initialize:serve_inner — most notably complete ListToolsResult payloads. With a large MCP tool catalog (~180 tools/connectors in our deployment), each such row is ~1.28 MB.

Measurements (read-only queries against logs_2.sqlite)
  • codex-cli 0.144.3, linux x86_64, app-server mode over stdio (embedded in a gateway product)
  • 290 rmcp::service rows >1 MB totaling 371 MB = 49% of a 751 MB file
  • 38-54 such rows/day = 50-68 MB/day sustained
  • TRACE overall = 84% of estimated_bytes in the DB
  • The built-in ~10-day retention bounds total size, but the write volume/WAL churn remains (this is the same SSD-endurance concern as #28224)
Notes
  • RUST_LOG in the parent environment does not affect the sqlite sink (consistent with #29463) — verified by restarting the parent with RUST_LOG=info,rmcp=warn and watching >1 MB rows continue to land.
Ask

Include rmcp::service (or rmcp*) in the persistent-log noisy-target filter introduced in #29457, and/or cap per-row payload size for the sqlite sink. A documented level/off knob for the sqlite sink would also serve (the sqlite_logs_enabled escape hatch discussed in #28224 was never merged).

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.