[GH-ISSUE #5068] [Bug] Call graph inventory rejects single-direction providers and omits required address lookup #3106

Closed
opened 2026-10-31 00:36:43 +00:00 by bsakaguchi · 1 comment
Owner

Originally created by @morluto on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5068

Before submitting

  • Searched open/closed issues and PRs for get_call_graph, inventory and procedure_address. #4687 concerns the sibling trace_call_path omission; PR #4729 changes only that sibling.
  • Only an authored two-node graph and controlled provider were used.

Area

Provider or capability discovery

Observed behavior

The public MCP session inventory contradicts get_call_graph execution:

Declared provider operations Inventory Actual call
procedure_address + procedure_callees unavailable, provider_missing Forward graph succeeds with both canonical nodes and complete direct relationship coverage.
procedure_address + procedure_callers unavailable, provider_missing Backward graph succeeds with both canonical nodes and complete direct relationship coverage.
Both relationship operations, no procedure_address available Both directions fail with capability_unavailable, naming procedure_address.
Both relationship operations, procedure_address unavailable available Both directions fail on address resolution; no provider execution occurs.

Reproduction

Executed through the production MCP server, registry, session and official InMemory SDK on main 3537e58c1ab29309f06eabf50bc52adba9817a0c, before changing production sources. A controlled provider maps start to 0x1000, goal to 0x2000, and observes the edge 0x1000 → 0x2000 with complete relationship coverage.

For each row, open an authored .hop target, call binary_session, then call get_call_graph with {address:"start", direction:"forward"} and {address:"goal", direction:"backward"}. Each row was executed once in the full six-scenario matrix. Direct execution assertions passed before inventory assertions failed. The no-target control correctly reports target_required; tools/list remains unchanged.

The regression command was node node_modules/vitest/vitest.mjs run --project mcp-boundary tests/boundary/mcp/callRelationshipAvailability.test.ts. It produced six inventory assertion failures and one passing no-target control; the other failures also exercise #4687. Local evidence: .cache/codebase-audit/call-availability-public-red-full.log and its extracted normalized results in call-availability-runtime-baseline.json.

Expected behavior

Inventory should require canonical address resolution plus the requested relationship direction. Expose forward/backward modes and whether the default forward mode is available. One working direction must remain discoverable; missing/unavailable mandatory address resolution must remain explicit.

Impact and scope

Incorrect inventory guidance can hide working graph traversal or recommend a call that cannot resolve its input. Observed with a controlled provider; NOT_ENOUGH_INFO for real-provider frequency or downstream incidents. No engine execution or target mutation.

REA version

6.7.0, source 3537e58c1ab29309f06eabf50bc52adba9817a0c.

Runtime and platform

Node 24.18.0, macOS arm64; official MCP SDK 2.3.1. No Linux/Windows or real-engine qualification.

Target and artifact context

Authored fixture target admitted by a controlled provider; two canonical procedure addresses and one direct call edge.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Missing-address control: inventory {name:"get_call_graph",available:true,reason:"available"}; execution error {code:"capability_unavailable",category:"unsupported_provider",details:{operation:"procedure_address",reason:"operation is not declared by this provider"}}.

Typed outcome or recovery expected

Preserve the address prerequisite and direction-specific missing operations/remediation in discovery. Keep actual typed execution failures and unknown/partial relationship results intact.

Analysis or suspected cause

Source-derived: CapabilityInventory.ts requires both relationship operations and omits address resolution. EnhancedTools.ts resolves procedure_address then selects only the requested relation. Independent duplicated descriptions of composition have drifted.

Additional context

Related #4687, PR #4729. A directly related shared-composition correction is being prepared on main. This report does not claim that PR #4729 fixes this sibling or that native providers were executed.

Originally created by @morluto on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5068 ### Before submitting - [x] Searched open/closed issues and PRs for `get_call_graph`, inventory and `procedure_address`. #4687 concerns the sibling `trace_call_path` omission; PR #4729 changes only that sibling. - [x] Only an authored two-node graph and controlled provider were used. ### Area Provider or capability discovery ### Observed behavior The public MCP session inventory contradicts `get_call_graph` execution: | Declared provider operations | Inventory | Actual call | | --- | --- | --- | | `procedure_address` + `procedure_callees` | unavailable, `provider_missing` | Forward graph succeeds with both canonical nodes and complete direct relationship coverage. | | `procedure_address` + `procedure_callers` | unavailable, `provider_missing` | Backward graph succeeds with both canonical nodes and complete direct relationship coverage. | | Both relationship operations, no `procedure_address` | available | Both directions fail with `capability_unavailable`, naming `procedure_address`. | | Both relationship operations, `procedure_address` unavailable | available | Both directions fail on address resolution; no provider execution occurs. | ### Reproduction Executed through the production MCP server, registry, session and official InMemory SDK on main `3537e58c1ab29309f06eabf50bc52adba9817a0c`, before changing production sources. A controlled provider maps `start` to `0x1000`, `goal` to `0x2000`, and observes the edge `0x1000 → 0x2000` with complete relationship coverage. For each row, open an authored `.hop` target, call `binary_session`, then call `get_call_graph` with `{address:"start", direction:"forward"}` and `{address:"goal", direction:"backward"}`. Each row was executed once in the full six-scenario matrix. Direct execution assertions passed before inventory assertions failed. The no-target control correctly reports `target_required`; tools/list remains unchanged. The regression command was `node node_modules/vitest/vitest.mjs run --project mcp-boundary tests/boundary/mcp/callRelationshipAvailability.test.ts`. It produced six inventory assertion failures and one passing no-target control; the other failures also exercise #4687. Local evidence: `.cache/codebase-audit/call-availability-public-red-full.log` and its extracted normalized results in `call-availability-runtime-baseline.json`. ### Expected behavior Inventory should require canonical address resolution plus the requested relationship direction. Expose forward/backward modes and whether the default forward mode is available. One working direction must remain discoverable; missing/unavailable mandatory address resolution must remain explicit. ### Impact and scope Incorrect inventory guidance can hide working graph traversal or recommend a call that cannot resolve its input. Observed with a controlled provider; NOT_ENOUGH_INFO for real-provider frequency or downstream incidents. No engine execution or target mutation. ### REA version 6.7.0, source `3537e58c1ab29309f06eabf50bc52adba9817a0c`. ### Runtime and platform Node 24.18.0, macOS arm64; official MCP SDK 2.3.1. No Linux/Windows or real-engine qualification. ### Target and artifact context Authored fixture target admitted by a controlled provider; two canonical procedure addresses and one direct call edge. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence Missing-address control: inventory `{name:"get_call_graph",available:true,reason:"available"}`; execution error `{code:"capability_unavailable",category:"unsupported_provider",details:{operation:"procedure_address",reason:"operation is not declared by this provider"}}`. ### Typed outcome or recovery expected Preserve the address prerequisite and direction-specific missing operations/remediation in discovery. Keep actual typed execution failures and unknown/partial relationship results intact. ### Analysis or suspected cause Source-derived: [CapabilityInventory.ts](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/CapabilityInventory.ts#L117) requires both relationship operations and omits address resolution. [EnhancedTools.ts](https://github.com/morluto/rea/blob/3537e58c1ab29309f06eabf50bc52adba9817a0c/src/application/EnhancedTools.ts#L444) resolves `procedure_address` then selects only the requested relation. Independent duplicated descriptions of composition have drifted. ### Additional context Related #4687, PR #4729. A directly related shared-composition correction is being prepared on main. This report does not claim that PR #4729 fixes this sibling or that native providers were executed.
Author
Owner

@morluto commented on GitHub (Oct 18, 2026):

Fixed in 1d5bf5ff0, covering #4687 and the independently reproduced sibling #5068.

The root cause was drift between runtime composition and discovery: a missing trace declaration, wrong graph prerequisites, and duplicated direction/default interpretation. Both tools now report forward/backward modes requiring address resolution plus the corresponding relationship operation. Overall availability and default-forward availability are separate; missing operations and owner failure remediation remain inline. Runtime and inventory share one direction mapping, defaults are selected by name, and the enhanced composition table is checked against canonical contract names so new omissions fail typechecking.

The correction adapts PR #4729's proposed missing trace composition, with co-author credit to AHMED. The final change also fixes the graph sibling and completes the directly related ownership/refactor and public-mode checks. This is not a merge or whole-head qualification of that PR.

Validation executed on macOS/Node24.18, official MCP SDK2.3.1 (negotiated protocol2025-11-25):

  • Before production edits, all six capability scenarios reproduced inventory failures after direct MCP execution assertions passed; the no-target control passed. One-direction graph traversal succeeded despite discovery refusing it; missing/unavailable address resolution failed while graph discovery claimed availability.
  • 75 source tests across four files and 76 public MCP/schema tests across eight files passed. The public matrix covers nine cases: both/single directions, missing/unavailable address lookup, unavailable forward relationship with usable backward mode, unsupported host, absent relationships, and no target. It preserves typed errors, graph node failures and unknown/partial traces. Same-endpoint address-only tracing remains callable without relationship reads; discovery is not a handler gate.
  • Full static/architecture checks, docs checks, check:fast and exact test discovery passed (1,589 files). SDK-converted schemas and compact-profile examples were validated. Independent source/design reviews found no blocker.

Completed MCP workflow costs were recorded using listTools → open_binary → binary_session → selected trace → close_binary plus awaited cleanup, three processes per variant/task (first process + two alternating repeated processes). The baseline uses the documented direct-invocation workaround to complete the same answer. Full catalog reply and normalized trace hashes agree across variants. Repeated medians:

Controlled task Estimated complete public-reply cl100k tokens Elapsed seconds CPU seconds Sampled peak process-family RSS, MB
Full provider, forward 820786 → 820953 2.142 → 2.142 2.816 → 2.835 739 → 741
Backward-only provider, backward 820785 → 820993 2.147 → 2.156 2.840 → 2.827 742 → 740

The complete full-profile catalog alone accounts for 805328 estimated tokens in these SDK observations; this is a wire-response estimate, not measured model context. Additional tokens carry mode/prerequisite facts. No true cold-cache or speedup claim; requests/framing, model selection/retries/host context, real providers, large/failure workload costs remain unmeasured.

Research used DeepWiki as navigation and checked the primary 2025-11-25 MCP tools specification, matching the observed negotiated version. Newer session-removal proposals in the current wiki were not applied. The fixed catalog policy and exact availability semantics remain owned by REA's contracts.

No native engine, CLI, Linux/Windows or model tool-selection qualification. Source-only follow-ups remain in native dispatch/UI composition prerequisites; those require separate runtime evidence. The wider codebase audit remains active.

<!-- gh-comment-id:6253960490 --> @morluto commented on GitHub (Oct 18, 2026): Fixed in [1d5bf5ff0](https://github.com/morluto/rea/commit/1d5bf5ff084b49c1c630a312520c59d6b08c6ade), covering #4687 and the independently reproduced sibling #5068. The root cause was drift between runtime composition and discovery: a missing trace declaration, wrong graph prerequisites, and duplicated direction/default interpretation. Both tools now report forward/backward modes requiring address resolution plus the corresponding relationship operation. Overall availability and default-forward availability are separate; missing operations and owner failure remediation remain inline. Runtime and inventory share one direction mapping, defaults are selected by name, and the enhanced composition table is checked against canonical contract names so new omissions fail typechecking. The correction adapts [PR #4729](https://github.com/morluto/rea/pull/4729)'s proposed missing trace composition, with co-author credit to AHMED. The final change also fixes the graph sibling and completes the directly related ownership/refactor and public-mode checks. This is not a merge or whole-head qualification of that PR. Validation executed on macOS/Node24.18, official MCP SDK2.3.1 (negotiated protocol2025-11-25): - Before production edits, all six capability scenarios reproduced inventory failures after direct MCP execution assertions passed; the no-target control passed. One-direction graph traversal succeeded despite discovery refusing it; missing/unavailable address resolution failed while graph discovery claimed availability. - 75 source tests across four files and 76 public MCP/schema tests across eight files passed. The public matrix covers nine cases: both/single directions, missing/unavailable address lookup, unavailable forward relationship with usable backward mode, unsupported host, absent relationships, and no target. It preserves typed errors, graph node failures and unknown/partial traces. Same-endpoint address-only tracing remains callable without relationship reads; discovery is not a handler gate. - Full static/architecture checks, docs checks, check:fast and exact test discovery passed (1,589 files). SDK-converted schemas and compact-profile examples were validated. Independent source/design reviews found no blocker. Completed MCP workflow costs were recorded using listTools → open_binary → binary_session → selected trace → close_binary plus awaited cleanup, three processes per variant/task (first process + two alternating repeated processes). The baseline uses the documented direct-invocation workaround to complete the same answer. Full catalog reply and normalized trace hashes agree across variants. Repeated medians: | Controlled task | Estimated complete public-reply cl100k tokens | Elapsed seconds | CPU seconds | Sampled peak process-family RSS, MB | | --- | --- | --- | --- | --- | | Full provider, forward | 820786 → 820953 | 2.142 → 2.142 | 2.816 → 2.835 | 739 → 741 | | Backward-only provider, backward | 820785 → 820993 | 2.147 → 2.156 | 2.840 → 2.827 | 742 → 740 | The complete full-profile catalog alone accounts for 805328 estimated tokens in these SDK observations; this is a wire-response estimate, not measured model context. Additional tokens carry mode/prerequisite facts. No true cold-cache or speedup claim; requests/framing, model selection/retries/host context, real providers, large/failure workload costs remain unmeasured. Research used DeepWiki as navigation and checked the [primary 2025-11-25 MCP tools specification](https://modelcontextprotocol.io/specification/2025-11-25/server/tools), matching the observed negotiated version. Newer session-removal proposals in the current wiki were not applied. The fixed catalog policy and exact availability semantics remain owned by REA's contracts. No native engine, CLI, Linux/Windows or model tool-selection qualification. Source-only follow-ups remain in native dispatch/UI composition prerequisites; those require separate runtime evidence. The wider codebase audit remains active.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#3106
No description provided.