[GH-ISSUE #5070] [Bug] Native dispatch inventory rejects a working direct metadata provider #3108

New issue

Closed

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

bsakaguchi commented

2026-10-31 00:36:43 +00:00

Owner

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

Area

Provider or capability discovery; MCP.

Observed behavior

At 1d5bf5ff084b49c1c630a312520c59d6b08c6ade, a controlled session provider advertising only inspect_native_dispatch_metadata successfully returns dispatch facts through that public MCP tool, but binary_session advertises it as available:false, reason:provider_missing, with remediation Configure a provider for required operation list_names.

Reproduction

Ran the production session/server through the official SDK InMemoryTransport using a controlled provider. Open the fixture session target, request binary_session, then call inspect_native_dispatch_metadata with max_records:10. The call returns the expected BuildViewController / buildTapped: implementation while the inventory claims the required provider is missing. The six-case boundary test has exactly one failing availability assertion on unchanged production; the direct runtime result succeeds. Symbol-only, absent operations, explicitly unavailable direct operation, direct runtime failure, and no-target controls pass.

Expected behavior

Discovery should admit the workflow with either its preferred direct operation or its symbol inventory fallback, matching src/application/native/NativeDispatchMetadataInspection.ts. Runtime failures must still propagate without fallback masking.

Impact and scope

Observed false-negative discovery for a direct-only controlled provider. A discovery-driven caller can skip a usable tool. No real Hopper/Ghidra/IDA/macOS reader execution or model tool-selection behavior was measured; those effects remain unverified.

REA version / runtime / target

Source 1d5bf5ff084b49c1c630a312520c59d6b08c6ade; pinned Node 24.18.0 on macOS arm64. Synthetic session target and provider facts, no real binary analysis.

Earliest failure stage

Transport or result projection: session capability inventory.

Relevant evidence and source-derived cause

Public boundary RED log: direct tool assertion succeeds before the inventory assertion fails with available:false / provider_missing. The committed regression will preserve this reproduction. CapabilityInventory.ts declares only list_names; the execution owner first invokes inspect_native_dispatch_metadata and falls back only on AnalysisCapabilityUnavailableError. The existing universal Mach-O unit test also pins the false negative. Searched open and closed issues; #4687/#5068 concern the related call traversal inventory defect rather than this native workflow.

Proposed structural fix

Share the workflow owner's named source operations with discovery and declare them as alternatives. Preserve target gates, typed runtime failure propagation, and bound-provider semantics. NOT_ENOUGH_INFO for real-engine and cross-host verification.

Originally created by @morluto on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5070 ### Area Provider or capability discovery; MCP. ### Observed behavior At `1d5bf5ff084b49c1c630a312520c59d6b08c6ade`, a controlled session provider advertising only `inspect_native_dispatch_metadata` successfully returns dispatch facts through that public MCP tool, but `binary_session` advertises it as `available:false`, `reason:provider_missing`, with remediation `Configure a provider for required operation list_names.` ### Reproduction Ran the production session/server through the official SDK InMemoryTransport using a controlled provider. Open the fixture session target, request `binary_session`, then call `inspect_native_dispatch_metadata` with `max_records:10`. The call returns the expected `BuildViewController` / `buildTapped:` implementation while the inventory claims the required provider is missing. The six-case boundary test has exactly one failing availability assertion on unchanged production; the direct runtime result succeeds. Symbol-only, absent operations, explicitly unavailable direct operation, direct runtime failure, and no-target controls pass. ### Expected behavior Discovery should admit the workflow with either its preferred direct operation or its symbol inventory fallback, matching `src/application/native/NativeDispatchMetadataInspection.ts`. Runtime failures must still propagate without fallback masking. ### Impact and scope Observed false-negative discovery for a direct-only controlled provider. A discovery-driven caller can skip a usable tool. No real Hopper/Ghidra/IDA/macOS reader execution or model tool-selection behavior was measured; those effects remain unverified. ### REA version / runtime / target Source `1d5bf5ff084b49c1c630a312520c59d6b08c6ade`; pinned Node 24.18.0 on macOS arm64. Synthetic session target and provider facts, no real binary analysis. ### Earliest failure stage Transport or result projection: session capability inventory. ### Relevant evidence and source-derived cause Public boundary RED log: direct tool assertion succeeds before the inventory assertion fails with `available:false` / `provider_missing`. The committed regression will preserve this reproduction. `CapabilityInventory.ts` declares only `list_names`; the execution owner first invokes `inspect_native_dispatch_metadata` and falls back only on `AnalysisCapabilityUnavailableError`. The existing universal Mach-O unit test also pins the false negative. Searched open and closed issues; #4687/#5068 concern the related call traversal inventory defect rather than this native workflow. ### Proposed structural fix Share the workflow owner's named source operations with discovery and declare them as alternatives. Preserve target gates, typed runtime failure propagation, and bound-provider semantics. NOT_ENOUGH_INFO for real-engine and cross-host verification.

bsakaguchi

2026-10-31 00:36:43 +00:00

closed this issue
added the
triage

bug
labels

bsakaguchi commented

2026-10-31 00:36:44 +00:00

Author

Owner

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

Fixed on main in 50b6975d86.

Root cause: the execution owner supports preferred direct metadata and a symbol fallback, while inventory duplicated only the fallback prerequisite. Discovery now consumes the workflow's named source operations as alternatives. Target gates and bound-provider semantics remain; runtime errors still propagate without masking.

Validation: the unchanged-production public MCP regression returned meaningful direct metadata then failed only the availability assertion. Final matrix passes 8 cases including symbol-only, neither source, unavailable direct with/without fallback, host denial with fallback, runtime failure, and no target. Related source tests pass 56; six public MCP/schema files pass 54, with the final 8-case rerun passing after fixture target/profile provenance was tightened. Full static/architecture, docs (5 checks), check:fast/pre-push, and discovery (1590 files exactly once) passed. Independent source review found no blocker.

Paired controlled completed SDK tasks retained identical 207-tool catalog and per-task metadata answers. Twelve workflows plus one smoke were measured; repeated-process medians direct-only: elapsed 2.459→2.139s, CPU 3.236→2.825s, sampled family RSS 801.3→738.4MB; symbol-only: 2.324→2.158s, 3.073→2.837s, 792.6→740.5MB. Full serialized SDK-response cl100k estimates change 821743→821821 and 821972→821969. These include the entire large catalog and duplicate public representations, not actual model context. Two repeated processes per variant/task, no cold-cache reset or speedup claim; real host delivery, requests/framing, agent retries and native engines unmeasured.

Real native readers/engines and cross-host behavior were not exercised. The separate UI trace inventory candidate remains under review; this closure does not claim it is fixed.

@morluto commented on GitHub (Oct 18, 2026): Fixed on main in 50b6975d861069e2c6cfa202780621449f863802. Root cause: the execution owner supports preferred direct metadata and a symbol fallback, while inventory duplicated only the fallback prerequisite. Discovery now consumes the workflow's named source operations as alternatives. Target gates and bound-provider semantics remain; runtime errors still propagate without masking. Validation: the unchanged-production public MCP regression returned meaningful direct metadata then failed only the availability assertion. Final matrix passes 8 cases including symbol-only, neither source, unavailable direct with/without fallback, host denial with fallback, runtime failure, and no target. Related source tests pass 56; six public MCP/schema files pass 54, with the final 8-case rerun passing after fixture target/profile provenance was tightened. Full static/architecture, docs (5 checks), check:fast/pre-push, and discovery (1590 files exactly once) passed. Independent source review found no blocker. Paired controlled completed SDK tasks retained identical 207-tool catalog and per-task metadata answers. Twelve workflows plus one smoke were measured; repeated-process medians direct-only: elapsed 2.459→2.139s, CPU 3.236→2.825s, sampled family RSS 801.3→738.4MB; symbol-only: 2.324→2.158s, 3.073→2.837s, 792.6→740.5MB. Full serialized SDK-response cl100k estimates change 821743→821821 and 821972→821969. These include the entire large catalog and duplicate public representations, not actual model context. Two repeated processes per variant/task, no cold-cache reset or speedup claim; real host delivery, requests/framing, agent retries and native engines unmeasured. Real native readers/engines and cross-host behavior were not exercised. The separate UI trace inventory candidate remains under review; this closure does not claim it is fixed.

bsakaguchi referenced this issue

2026-10-31 01:08:03 +00:00

[PR #3108] [MERGED] fix(setup): refuse linked skill installation directories #5621

bsakaguchi referenced this issue

2026-10-31 01:08:04 +00:00

[PR #3109] [CLOSED] fix(setup): retain symbolic-link skill destinations across the lifecycle #5624

bsakaguchi referenced this issue

2026-10-31 01:08:32 +00:00

[PR #3257] [CLOSED] test(pcap): expect the producer's final stdout newline #5676