morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4623] [Bug] Embedded-provider procedure completion drops a second name at the same address #2404

New issue

Closed

opened 2026-10-17 21:04:14 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-17 21:04:14 +00:00

Owner

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

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

MCP or agent integration

Observed behavior

When a custom embedded analysis provider returns foo and bar at 0x1000, list_procedures retains both rows, but guided prompt completion offers only 0x1000 and foo. Prefix bar returns no suggestions. Reversing the rows retains bar and drops foo. This reproduces through the fixed-source createServer seam that the source explicitly identifies for embedders, on both tested builds.

This report concerns a caller-supplied embedded inventory. No built-in analysis engine was observed returning duplicate-address procedure rows. The current Hopper, Ghidra, IDA and Kuna producer paths inspected do not enumerate aliases as separate same-address procedure rows, so ordinary engine-workflow incidence is not established.

Reproduction

Use either tested build below with its runtime dependencies installed. For the source checkout, run npm ci and npm run build:cached first. For the npm artifact, run from the installed rea-agents package directory.
Run this from that directory. It uses an isolated HOME, the production MCP server and SDK in-memory transport, and a fixed analysis provider. It does not open an executable or start an analysis engine.

example_home="$(mktemp -d)"
env -i HOME="$example_home" PATH="$PATH" node --input-type=module <<'JS'
import { createRequire } from 'node:module';
import { pathToFileURL } from 'node:url';
import { resolve } from 'node:path';
import assert from 'node:assert/strict';
const root = resolve('.');
const require = createRequire(resolve(root, 'package.json'));
const { Client, InMemoryTransport } = await import(pathToFileURL(require.resolve('@modelcontextprotocol/client')));
const { createServer } = await import(pathToFileURL(resolve(root, 'dist/server/createServer.js')));
const { createAnalysisExecution } = await import(pathToFileURL(resolve(root, 'dist/application/AnalysisProvider.js')));
const foo = { address: '0x1000', value: 'foo' };
const bar = { address: '0x1000', value: 'bar' };
const provider = { id: 'example', name: 'Example analysis provider', version: '1' };
for (const [label, rows] of [['same-address', [foo, bar]], ['reversed', [bar, foo]], ['distinct-addresses', [foo, { ...bar, address: '0x2000' }]], ['ambiguous-name', [foo, { ...foo, address: '0x2000' }]]]) {
  const server = createServer({ kind: 'fixed', analysis: {
    execute: async operation => ({ ok: true, value: createAnalysisExecution(operation === 'list_procedures' ? rows : [], provider) })
  } });
  const client = new Client({ name: 'procedure-completion-example', version: '1' });
  const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
  try {
    await server.connect(serverTransport);
    await client.connect(clientTransport);
    const inventory = await client.callTool({ name: 'list_procedures', arguments: {} });
    assert.notEqual(inventory.isError, true);
    assert.deepEqual(inventory.structuredContent.normalized_result, rows);
    console.log(label, 'inventory', JSON.stringify(rows));
    for (const value of ['', 'foo', 'bar']) {
      const result = await client.complete({ ref: { type: 'ref/prompt', name: 'investigate_feature' }, argument: { name: 'procedure', value } });
      console.log(label, JSON.stringify({ value, result }));
    }
  } finally {
    await client.close();
    await server.close();
  }
}
JS
rm -rf "$example_home"

Compare the same-address and reversed output with the distinct-address and ambiguous-name controls. Each case ran in a separate server instance once per build, and every server/client close completed successfully. The simulated-provider stdio route also reproduced the same omission on both builds after opening a local target and warming the provider with list_procedures; that route does not establish real-engine emission of the inventory.

Expected behavior

The documented procedure-completion rule derives candidates from the complete list_procedures inventory and offers names that identify exactly one address. Both foo and bar identify one address here. Empty-prefix completion should return 0x1000, bar and foo, and prefix bar should return bar in either row order. A name shared by two distinct addresses should remain excluded.

Impact and scope

Custom embedded providers can expose a valid procedure name through the inventory while completion silently omits it. The result depends on row order. The inventory and shared address remain available. No deployed affected embedder, production-engine alias loss, manual-name-selection failure or analysis-data loss was demonstrated.

Impact level: P2
Assessment status: provisional
Impact basis: The embedding reproduction demonstrates a bounded completion-contract failure for an accepted inventory; external incidence and ordinary built-in-provider reach remain unestablished.
Workaround status: available
Workaround basis: The observed inventory retains both rows and completion still offers their shared address, allowing the caller to select the procedure by address.

REA version

Published npm rea-agents@6.5.0, and current main source commit 0c7b6d834af2d044b23196e0e522cc2468327a1e built with the pinned toolchain.

Runtime and platform

Node v24.18.0; npm 11.16.0; macOS 27.0.1 arm64. No Hopper, Ghidra, IDA or Kuna engine was started.

Target and artifact context

The reproduction supplies an inline custom AnalysisOperationPort inventory through createServer({ kind: "fixed", analysis }). It uses no target binary or provider database.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

Expected source: docs/mcp-prompts.md:103,112-115 documents complete-inventory, unique-address name completion. src/server/createServer.ts:282-287 explicitly identifies the fixed-target seam for tests and embedders; src/server/analysisAdmission.ts:15-18 defines its fixed-source input without an address-uniqueness restriction.
Failure source: The MCP reproduction above returns the following results on both tested builds; src/server/promptCompletion.ts:118-119 keeps only the first inventory row at each address before evaluating name uniqueness.
Evidence provenance: observed
Local verification: reproduced
Reproduction completeness: complete

Same-address output:

inventory [{"address":"0x1000","value":"foo"},{"address":"0x1000","value":"bar"}]
{"value":"","result":{"completion":{"values":["0x1000","foo"],"total":2,"hasMore":false}}}
{"value":"foo","result":{"completion":{"values":["foo"],"total":1,"hasMore":false}}}
{"value":"bar","result":{"completion":{"values":[],"total":0,"hasMore":false}}}

Reversed rows produce empty-prefix values ["0x1000","bar"] and no prefix-foo suggestions. Distinct addresses produce ["0x1000","0x2000","bar","foo"] and both name prefixes work. The ambiguous-name control correctly produces only ["0x1000","0x2000"]; prefix foo returns no suggestions. Both embedding runs exited successfully with empty stderr.

Source-derived reachability: a fixed-source completion reads AnalysisOperationPort.execute directly in completionInventoryLookup; the result schema accepts both address/value rows. Normal CLI/MCP startup instead supplies a session-backed source. Source comments establish an embedding seam, but no stable public JavaScript SDK guarantee or deployed consumer is asserted here.

Typed outcome or recovery expected

With the same-address inventory, prefix bar should return { "completion": { "values": ["bar"], "total": 1, "hasMore": false } }. Empty-prefix completion should retain both distinct names and the shared address regardless of row order. Preserve the distinct-address control and continue excluding foo when the complete inventory associates it with two addresses.

Analysis or suspected cause

Source-derived explanation: address deduplication discards the later name before name-to-address uniqueness is calculated. This explains the observed row-order dependence. No particular repair is required by this report.

Additional context

This is a conditional embedding case. Built-in provider aliases stored in list_names or a separate alias field do not by themselves establish the required list_procedures input. The fixed-source reproduction supplies that input explicitly. No known-good release or regression boundary was established. Open/closed issue and PR searches found related completion reports but no exact duplicate of this same-address, later-name omission.

Originally created by @coygeek on GitHub (Oct 17, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4623 ### Before submitting - [X] I searched the open and closed issues for a related report. - [X] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Observed behavior When a custom embedded analysis provider returns `foo` and `bar` at `0x1000`, `list_procedures` retains both rows, but guided prompt completion offers only `0x1000` and `foo`. Prefix `bar` returns no suggestions. Reversing the rows retains `bar` and drops `foo`. This reproduces through the fixed-source `createServer` seam that the source explicitly identifies for embedders, on both tested builds. This report concerns a caller-supplied embedded inventory. No built-in analysis engine was observed returning duplicate-address procedure rows. The current Hopper, Ghidra, IDA and Kuna producer paths inspected do not enumerate aliases as separate same-address procedure rows, so ordinary engine-workflow incidence is not established. ### Reproduction 1. Use either tested build below with its runtime dependencies installed. For the source checkout, run `npm ci` and `npm run build:cached` first. For the npm artifact, run from the installed `rea-agents` package directory. 2. Run this from that directory. It uses an isolated HOME, the production MCP server and SDK in-memory transport, and a fixed analysis provider. It does not open an executable or start an analysis engine. ```sh example_home="$(mktemp -d)" env -i HOME="$example_home" PATH="$PATH" node --input-type=module <<'JS' import { createRequire } from 'node:module'; import { pathToFileURL } from 'node:url'; import { resolve } from 'node:path'; import assert from 'node:assert/strict'; const root = resolve('.'); const require = createRequire(resolve(root, 'package.json')); const { Client, InMemoryTransport } = await import(pathToFileURL(require.resolve('@modelcontextprotocol/client'))); const { createServer } = await import(pathToFileURL(resolve(root, 'dist/server/createServer.js'))); const { createAnalysisExecution } = await import(pathToFileURL(resolve(root, 'dist/application/AnalysisProvider.js'))); const foo = { address: '0x1000', value: 'foo' }; const bar = { address: '0x1000', value: 'bar' }; const provider = { id: 'example', name: 'Example analysis provider', version: '1' }; for (const [label, rows] of [['same-address', [foo, bar]], ['reversed', [bar, foo]], ['distinct-addresses', [foo, { ...bar, address: '0x2000' }]], ['ambiguous-name', [foo, { ...foo, address: '0x2000' }]]]) { const server = createServer({ kind: 'fixed', analysis: { execute: async operation => ({ ok: true, value: createAnalysisExecution(operation === 'list_procedures' ? rows : [], provider) }) } }); const client = new Client({ name: 'procedure-completion-example', version: '1' }); const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair(); try { await server.connect(serverTransport); await client.connect(clientTransport); const inventory = await client.callTool({ name: 'list_procedures', arguments: {} }); assert.notEqual(inventory.isError, true); assert.deepEqual(inventory.structuredContent.normalized_result, rows); console.log(label, 'inventory', JSON.stringify(rows)); for (const value of ['', 'foo', 'bar']) { const result = await client.complete({ ref: { type: 'ref/prompt', name: 'investigate_feature' }, argument: { name: 'procedure', value } }); console.log(label, JSON.stringify({ value, result })); } } finally { await client.close(); await server.close(); } } JS rm -rf "$example_home" ``` 3. Compare the `same-address` and `reversed` output with the distinct-address and ambiguous-name controls. Each case ran in a separate server instance once per build, and every server/client close completed successfully. The simulated-provider stdio route also reproduced the same omission on both builds after opening a local target and warming the provider with `list_procedures`; that route does not establish real-engine emission of the inventory. ### Expected behavior The documented procedure-completion rule derives candidates from the complete `list_procedures` inventory and offers names that identify exactly one address. Both `foo` and `bar` identify one address here. Empty-prefix completion should return `0x1000`, `bar` and `foo`, and prefix `bar` should return `bar` in either row order. A name shared by two distinct addresses should remain excluded. ### Impact and scope Custom embedded providers can expose a valid procedure name through the inventory while completion silently omits it. The result depends on row order. The inventory and shared address remain available. No deployed affected embedder, production-engine alias loss, manual-name-selection failure or analysis-data loss was demonstrated. - Impact level: P2 - Assessment status: provisional - Impact basis: The embedding reproduction demonstrates a bounded completion-contract failure for an accepted inventory; external incidence and ordinary built-in-provider reach remain unestablished. - Workaround status: available - Workaround basis: The observed inventory retains both rows and completion still offers their shared address, allowing the caller to select the procedure by address. ### REA version Published npm `rea-agents@6.5.0`, and current `main` source commit `0c7b6d834af2d044b23196e0e522cc2468327a1e` built with the pinned toolchain. ### Runtime and platform Node v24.18.0; npm 11.16.0; macOS 27.0.1 arm64. No Hopper, Ghidra, IDA or Kuna engine was started. ### Target and artifact context The reproduction supplies an inline custom `AnalysisOperationPort` inventory through `createServer({ kind: "fixed", analysis })`. It uses no target binary or provider database. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence - Expected source: `docs/mcp-prompts.md:103,112-115` documents complete-inventory, unique-address name completion. `src/server/createServer.ts:282-287` explicitly identifies the fixed-target seam for tests and embedders; `src/server/analysisAdmission.ts:15-18` defines its fixed-source input without an address-uniqueness restriction. - Failure source: The MCP reproduction above returns the following results on both tested builds; `src/server/promptCompletion.ts:118-119` keeps only the first inventory row at each address before evaluating name uniqueness. - Evidence provenance: observed - Local verification: reproduced - Reproduction completeness: complete Same-address output: ```text inventory [{"address":"0x1000","value":"foo"},{"address":"0x1000","value":"bar"}] {"value":"","result":{"completion":{"values":["0x1000","foo"],"total":2,"hasMore":false}}} {"value":"foo","result":{"completion":{"values":["foo"],"total":1,"hasMore":false}}} {"value":"bar","result":{"completion":{"values":[],"total":0,"hasMore":false}}} ``` Reversed rows produce empty-prefix values `["0x1000","bar"]` and no prefix-`foo` suggestions. Distinct addresses produce `["0x1000","0x2000","bar","foo"]` and both name prefixes work. The ambiguous-name control correctly produces only `["0x1000","0x2000"]`; prefix `foo` returns no suggestions. Both embedding runs exited successfully with empty stderr. Source-derived reachability: a fixed-source completion reads `AnalysisOperationPort.execute` directly in `completionInventoryLookup`; the result schema accepts both address/value rows. Normal CLI/MCP startup instead supplies a session-backed source. Source comments establish an embedding seam, but no stable public JavaScript SDK guarantee or deployed consumer is asserted here. ### Typed outcome or recovery expected With the same-address inventory, prefix `bar` should return `{ "completion": { "values": ["bar"], "total": 1, "hasMore": false } }`. Empty-prefix completion should retain both distinct names and the shared address regardless of row order. Preserve the distinct-address control and continue excluding `foo` when the complete inventory associates it with two addresses. ### Analysis or suspected cause Source-derived explanation: address deduplication discards the later name before name-to-address uniqueness is calculated. This explains the observed row-order dependence. No particular repair is required by this report. ### Additional context This is a conditional embedding case. Built-in provider aliases stored in `list_names` or a separate alias field do not by themselves establish the required `list_procedures` input. The fixed-source reproduction supplies that input explicitly. No known-good release or regression boundary was established. Open/closed issue and PR searches found related completion reports but no exact duplicate of this same-address, later-name omission.

bsakaguchi closed this issue

2026-10-31 00:33:34 +00:00

bsakaguchi commented

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

Author

Owner

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

Fixed on main in d3627b1038.

The root cause was an address-keyed intermediate map: keeping only the first row discarded aliases before name uniqueness was evaluated, and could also hide ambiguity in later rows. Completion now parses the existing address/value contract once, derives exact address suggestions separately, and tracks each name as either tied to one address or explicitly ambiguous across every inventory row. Returned provider spellings remain intact. Ambiguity is evaluated before the SDK applies its 100-result reply limit.

Validated through the public MCP SDK with same-address aliases/duplicates, forward and reverse inventories, later ambiguity and rows beyond the reply limit. The three new cases fail against unchanged6296fdf56 and pass with the fix. Final focused run:43 passing tests across5 files (40 completion/schema tests plus3 cases from the incoming setup commit); full npm run check, docs:check (5), and test discovery (1606 files) passed. Controlled embedded-provider inventory only; no built-in/native-engine alias incidence claimed.

Twelve paired completed SDK cost workflows (4-row/5000-row stable inventories, before the unrelated incoming setup commit) preserved exact catalog, Evidence and completion output. Warm medians were2.119→2.209s and2.032→2.054s; CPU2.802→2.891s and2.734→2.746s; sampled process-family RSS713.1→714.9MB and725.3→730.1MB. Full serialized reply estimates remained702045/854693 cl100k_base tokens; whole-agent context and true cold costs were not measured. No performance improvement claimed.

Adapted after full review of #4648 at5b019e1179dce76f432c0f5700161de5727b8a96, with contributor credit in the commit. That PR was not merged.

@morluto commented on GitHub (Oct 19, 2026): Fixed on main in d3627b10382b0f28b12cad1543634e165470b29a. The root cause was an address-keyed intermediate map: keeping only the first row discarded aliases before name uniqueness was evaluated, and could also hide ambiguity in later rows. Completion now parses the existing address/value contract once, derives exact address suggestions separately, and tracks each name as either tied to one address or explicitly ambiguous across every inventory row. Returned provider spellings remain intact. Ambiguity is evaluated before the SDK applies its 100-result reply limit. Validated through the public MCP SDK with same-address aliases/duplicates, forward and reverse inventories, later ambiguity and rows beyond the reply limit. The three new cases fail against unchanged6296fdf56 and pass with the fix. Final focused run:43 passing tests across5 files (40 completion/schema tests plus3 cases from the incoming setup commit); full npm run check, docs:check (5), and test discovery (1606 files) passed. Controlled embedded-provider inventory only; no built-in/native-engine alias incidence claimed. Twelve paired completed SDK cost workflows (4-row/5000-row stable inventories, before the unrelated incoming setup commit) preserved exact catalog, Evidence and completion output. Warm medians were2.119→2.209s and2.032→2.054s; CPU2.802→2.891s and2.734→2.746s; sampled process-family RSS713.1→714.9MB and725.3→730.1MB. Full serialized reply estimates remained702045/854693 cl100k_base tokens; whole-agent context and true cold costs were not measured. No performance improvement claimed. Adapted after full review of #4648 at5b019e1179dce76f432c0f5700161de5727b8a96, with contributor credit in the commit. That PR was not merged.

bsakaguchi referenced this issue

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

[PR #2404] [MERGED] test(evm): verify real worker cancellation and cleanup recovery #5204

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#2404

No description provided.

Rows
Columns