Repository navigation
[bug] Route extractor over-fits: GraphQL query literals, whole config-file contents, and regex literals become Route nodes #598
Description
Version: codebase-memory-mcp v0.8.1 (Windows, compiled .exe)
Project: real-world repo, 93,315 nodes, 996 Route nodes
Summary
Route extraction classifies many non-route strings as routes. On our repo, 46 of 996 routes are clearly junk, and the empty-source bucket mixes real HTTP endpoints with regex/path string literals.
Repro
search_graph(label="Route") then group by source:
source |
count | what they actually are |
|---|---|---|
decorator |
41 | ✅ real Flask/Django route decorators (correct) |
"" (empty) |
909 | real API paths from frontend HTTP calls + regex/path literals |
graphql |
34 | ❌ entire GraphQL query string literals (query { categoryList {...} }) turned into one Route node each |
infra |
12 | ❌ the entire text of .codex/agents/*.toml files turned into a single Route node |
Empty-source junk samples (method=ANY, degree 0):
/.{2}/g, /<table/i (JS regex literals), /_VBA_PROJECT_CUR/VBA/dir, /::/, /.well-known/openid-configuration.
Minimal example
// a JS regex literal — NOT a route
const re = /<table/i;# a query string passed to a client — NOT a route
query { products(search: "x") { items { sku } } }Both currently produce Route nodes.
Expected
- Route extraction should require an actual route declaration (decorator/router registration/framework binding), not "string contains slashes" or "file looks like config".
- GraphQL query literals should not be
Route(aGraphQLOperationlabel would be fine). - Config/agent files (
.codex/*.toml,*.md) should not have their whole contents emitted as a single Route. - At minimum: don't classify regex literals (
/…/[gimsuy]) as routes.
Workaround (consumer side)
Filter WHERE r.source='decorator' OR (r.method IS NOT NULL AND r.method <> 'ANY') → 996 → 347, junk removed. But this loses real decorator-less routes inconsistently; a clean extractor is preferable.
Related
Distinct from the exclude-config issues (#500/#510) — this is mis-classification of content, not indexing of build artifacts.
Activity
DeusData commentedon Jun 29, 2026
Thanks. I’ve triaged this under #592. The route extractor needs stronger source/kind filters so GraphQL, config-file text, and regex literals do not become
Routenodes; focused fixtures for each false-positive bucket should pin this down.DeusData commentedon Sep 26, 2026
Thank you, @ecosuper2025, for the per-
sourcebreakdown; it gave each false-positive class its own target!On current main we can no longer produce Route nodes from JS regex literals, from
.codex/agents/*.tomlcontents or from document-style paths, and our GraphQL client repros didn't create one either. One real remaining gap is in the code: when a call does resolve to a GraphQL client, the Route is named after the whole operation string, so an anonymousquery { … }still becomes one long Route name. We'll switch that to use the operation name only.Could you re-index on v0.11.0 and tell us which of your four buckets still show up? The counts per
sourcewould be perfect.fix(pipeline): key GraphQL Routes by operation name, not operation te…
DeusData commentedon Oct 19, 2026
Thank you again for separating the route false-positive buckets. If you have done the requested reindex on a newer version, the per-source counts would help compare the remaining GraphQL case. I have no new verification beyond the September update, and the operation-name change remains maintainer work.
DeusData commentedon Oct 25, 2026
Thank you for your patience. Sorry for the delay. GraphQL operation naming remains maintainer work; existing per-source retest results are welcome but need not be recreated. I’ll follow up soon.