## Summary Systematic comparison of MCP endpoint responses (`POST /api/v4/orbit/mcp`) against the GitLab REST API on staging revealed 5 data correctness issues. Testing used `tools/call` with `query_graph` and compared results field-by-field against equivalent REST API calls. **Environment:** staging.gitlab.com, tested 2026-03-25 **Finished Checklist**: - [x] Bug 1: `full_path` contains slug instead of namespaced path (Project + Group) (@michaelusa) - [ ] Bug 2: MEMBER_OF edges severely incomplete (~93% missing) - (@michaelangeloio) - [ ] Bug 3: Job `failure_reason` defaults to `"unknown"` instead of null (@michaelusa) - [x] Bug 4: Milestone `due_date` always null (@michaelangeloio) - [x] Bug 5: Ungrouped aggregation results invisible in LLM format (@michaelusa, !704) --- ## Bug 1: `full_path` contains slug instead of namespaced path (Project + Group) **Severity:** High — `full_path` is a default column and the primary way users identify projects/groups. **Root cause:** `config/ontology/nodes/core/project.yaml:28` and `group.yaml:28` both have `source: path`, which maps to the project/group slug. The ontology field is named `full_path` but it pulls the wrong source column. **Reproduction:** ```json // MCP query {"query_type":"search","node":{"id":"p","entity":"Project","columns":["name","full_path"],"node_ids":[278964]},"limit":1} ``` | Source | Value | |--------|-------| | MCP `full_path` | `"gitlab"` | | REST `path_with_namespace` | `"gitlab-org/gitlab"` | | REST `path` (slug) | `"gitlab"` | Same for subgroups: | Group ID | MCP `full_path` | REST `full_path` | |----------|-----------------|------------------| | 1540914 | `"gitter"` | `"gitlab-org/gitter"` | | 1602322 | `"database-specialists"` | `"gitlab-org/database-specialists"` | | 1755573 | `"frontend"` | `"gitlab-org/frontend"` | **Fix:** Change `source: path` to the correct Siphon source column that contains the namespaced path (e.g., `full_path` or `path_with_namespace` depending on what Siphon exposes) in both `project.yaml` and `group.yaml`. --- ## Bug 2: MEMBER_OF edges severely incomplete (~93% missing) **Severity:** High — membership queries return a small fraction of actual members. **Reproduction:** ```json // MCP: count members of gitlab-org/gitlab {"query_type":"traversal","nodes":[{"id":"p","entity":"Project","node_ids":[278964]},{"id":"u","entity":"User","columns":["username"]}],"relationships":[{"type":"MEMBER_OF","from":"u","to":"p"}],"limit":1000} ``` | Source | Member count | |--------|-------------| | MCP (MEMBER_OF edges) | 41 | | REST (`/projects/278964/members/all`) | 609 | The two sets have zero overlap in their first pages. MCP returns users like 58926 (Haydn Mackay, Reporter access) which ARE valid members per REST, but the core maintainers/owners (user 1, 444, etc.) are absent from MCP. **Likely cause:** Inherited group memberships may not be flowing through Siphon CDC, or the indexer only captures direct project memberships. --- ## Bug 3: Job `failure_reason` defaults to `"unknown"` instead of null **Severity:** Low — cosmetic, but could confuse LLM consumers into thinking jobs failed. **Reproduction:** ```json // MCP: get jobs in gitlab-org/gitlab {"query_type":"traversal","nodes":[{"id":"p","entity":"Project","node_ids":[278964]},{"id":"j","entity":"Job","columns":"*"}],"relationships":[{"type":"IN_PROJECT","from":"j","to":"p"}],"limit":3} ``` Job 40962453 ("jest 4/5", status=canceled): | Source | `failure_reason` | |--------|-----------------| | MCP | `"unknown"` | | REST (`/projects/278964/jobs/40962453`) | `null` | **Fix:** The indexer or ClickHouse default should use null/empty instead of `"unknown"` when no failure reason exists. --- ## Bug 4: Milestone `due_date` always null **Severity:** Medium — milestone dates are important for planning queries. **Reproduction:** ```json // MCP: search milestones {"query_type":"search","node":{"id":"m","entity":"Milestone","columns":"*"},"limit":5} ``` Milestone 349690 ("10.1"): | Source | `due_date` | |--------|-----------| | MCP | `null` | | REST (`/groups/9970/milestones/349690`) | `"2017-10-22"` | All 20 milestones tested had `due_date: null` in MCP. The field exists in the ontology schema but values aren't being indexed. --- ## Bug 5: Ungrouped aggregation results invisible in LLM format **Severity:** Medium — scalar counts (the most common aggregation) return no usable data to MCP/LLM consumers. **Reproduction:** ```json // MCP: count all projects {"query_type":"aggregation","nodes":[{"id":"p","entity":"Project"}],"aggregations":[{"function":"count","target":"p","alias":"total"}]} ``` Response: `row_count: 1` but the result body is `{"query_type":"aggregation","nodes":[],"edges":[]}`. The actual count value is absent. The SQL is correct (`SELECT COUNT(p.id) AS total`) and returns one row. But the GOON formatter maps results into `nodes` and `edges` — a scalar aggregation has neither, so the value is silently dropped. **Grouped aggregations work fine.** For example, counting jobs per project returns `job_count` as a property on each Project node. The bug only affects ungrouped (scalar) aggregations. --- ## What's working correctly - SQL injection is safe (parameterized queries) - Schema validation rejects invalid entities, relationships, limits (0, 1001), empty arrays - Unknown tool names return proper JSON-RPC `-32602` errors - Star counts, MR fields (title, state, source_branch, iid), job names/statuses all match REST - Path finding, neighbors, contains/gt/in filters all work - Security redaction is enforced (results scoped to authorized traversal paths) - Grouped aggregations return correct counts (e.g., 10.9M jobs for gitlab-org/gitlab) <!-- AI-Sessions dir: ~/.claude/projects/-Users-angelo-rivera-gitlab-orbit-knowledge-graph/ c73bc421-43cf-4625-a30b-a87f322261e4.jsonl (2026-03-25) -->