Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

ingest_traces` reports `pairs_unmatched` for endpoints that `query_graph` serves; first large batch stores, all subsequent calls unmatched (fresh index/daemon reproduce)

Aperta
  • Qualcosa non va?
#2,725 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, sqlite
Ambito
backend, databases

Direzione di ricerca

Start with the endpoint validation in src/mcp/mcp.c and the nodes schema in src/store/store.c; compare the ingest lookup with how query_graph resolves qualified names. Reproduce the minimal two-file case described in the issue and inspect the result of ingesting an existing pair. Done means traces whose endpoints exist in the current generation are stored and the minimal reproduction reports the pair as stored.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

awaiting-reporter bug cypher editor/integration parsing/quality stability/performance
Version

codebase-memory-mcp 0.12.1 (build 77745491f0a9), Linux x86-64, installed 2026-10-20 via the official installer.

Platform

Linux (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Issue: ingest_traces rejects pairs whose endpoints exist in the graph

Title: ingest_traces reports pairs_unmatched for endpoints that query_graph serves; first large batch stores, all subsequent calls unmatched (fresh index/daemon reproduce)

Environment

  • codebase-memory-mcp 0.12.1 (build 77745491f0a9), Linux x86-64, installed 2026-10-20 via the official installer.
  • Project: legacy monorepo, ~42k nodes / ~152k edges after .cbmignore exclusions (Perl + PL/pgSQL + Go + Template Toolkit).
  • Client: MCP session from Kimi Code CLI.

Summary

ingest_traces validates endpoints with SELECT 1 FROM nodes WHERE project=? AND qualified_name=? (per src/mcp/mcp.c). On a fresh index, single-trace calls with endpoints that query_graph returns are rejected as unmatched, and pairs_stored stays 0. The first large batch (~250 traces) stored 249 pairs; every call after that — including re-sending previously stored pairs and pairs that are real CALLS edges returned by query_graph — is rejected. pair_total freezes at the value reached after the second batch.

Additional observations

  • Reproduces after: daemon stop/client restart; delete_project + full reindex from scratch (fresh DB, ~37 s build); single-trace minimal payload. So it is not stale state or a corrupted store.
  • Reproduces on a minimal project (two .py files, 3 nodes, 1 CALLS edge): ingesting exactly the pair returned by MATCH (a)-[r:CALLS]->(b) gives pairs_unmatched: 1. Not specific to the original project.
  • The node data is present in the project .db file (verified with strings on nodes rows: project, label, qualified_name, file_path).
  • Schema (src/store/store.c): single nodes table, UNIQUE(project, qualified_name) — so the exists-check query shape looks correct.
  • Related quirk: query_graph with WHERE n.qualified_name = '<qn>' returns 0 rows, while WHERE n.qualified_name IN ['<qn>'] finds the node, and WHERE f.file_path = ... AND f.name = ... finds it and RETURNs exactly that qualified_name. Suggests equality matching on qualified_name is tokenized/broken in the cypher layer; possibly the same lookup is used by the ingest validation.
  • One large batch behaved differently: the very first ingest_traces call (~250 pairs) stored 249/250; everything after was rejected. Looks like a write-transaction/visibility window rather than per-pair validation logic.

Expected behavior

A trace whose both endpoint qns resolve to nodes in the current generation is stored (pairs_stored increments, visible to trace_path overlay).

Use case behind the ingest

Linking Template Toolkit page templates to the PL/pgSQL API functions they call via a dispatcher (api('info.date') in templates → method registered in a ws.method INSERT → implementing function). Static analysis can't see these edges; runtime/derived traces are the only way. Because the API method itself (info.date) is a data registration, not a code symbol, there is no node for it — see feature request below.

Feature request: user-defined node layer (or ingest with node creation)

For systems where an "API method" is a row in a registry table rather than a declared symbol, it would be valuable to declare a custom layer of nodes (e.g. ApiMethod labeled nodes keyed by method name) and then ingest observed edges Template -> ApiMethod -> Function. Currently ingest_traces must not fabricate nodes (per RUNTIME_TRACE_MODEL.md), and no MCP surface creates nodes — so such edges are impossible without synthetic bridge files in the indexed tree. A declare_nodes/upsert_nodes tool (scoped to a label, replaceable per re-generation) would cover this class of use cases cleanly.

Reproduction

Minimal reproduction

  1. Index a project (full mode). Confirm a node exists:

    query_graph: MATCH (f:Function) WHERE f.file_path = 'pwl/sql/ws/52_i18n_dep.sql' AND f.name = 'date_info' RETURN f.qualified_name
    → home-app_test-tpro2.pwl.sql.ws.52_i18n_dep.date_info

  2. Ingest a trace with exactly that qn:

    ingest_traces(
  project = "home-app_test-tpro2",
  label   = "repro",
  traces  = [{"caller": "home-app_test_tpro2.pwl.tmpl.page.app.administrate_messages",
              "callee": "home-app_test_tpro2.pwl.sql.ws.52_i18n_dep.date_info",
              "count": 1}]
)

  3. Response:

    {"status":"stored","pairs_stored":0,"pairs_unmatched":1,
 "unmatched_sample":["home-app_test_tpro2.pwl.tmpl.page.app.administrate_messages",
                     "home-app_test-tpro2.pwl.sql.ws.52_i18n_dep.date_info"],
 "pair_total":0}

Both endpoints are served by query_graph (the Module node exists: MATCH (m:Module) WHERE m.file_path = '...administrate_messages.tt2' RETURN count(m) → 1). Reproduces with a pair taken verbatim from a MATCH (a)-[r:CALLS]->(b) query as well.

Logs
Diagnostics trajectory (memory / performance / leak issues)
Project scale (if relevant)

No response

Confirmations
  • I searched existing issues and this is not a duplicate.
  • My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 14h
PR unite (30g)
210

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.