[GH-ISSUE #1724] [Bug] Unknown update mutation Evidence omits caller-selected state and conflates different requests #577

New issue

Closed

opened 2026-10-15 18:26:22 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:22 +00:00

Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

Two different successful update_unknown requests can create identical mutation Evidence. In a real stdio MCP reproduction, the same revision-1 Unknown was imported into two fresh sessions. One request changed severity to high, the other to low; both kept status open. The returned Unknown states and revision digests differed, but both exports contained the same update_unknown mutation Evidence ID, parameters and result. Its Evidence did not contain either requested severity.

Reproduction

Start REA stdio MCP with the source version below and SDK client 2.3.1.
Call record_unknown with this input, then export its bundle and retain the returned unknown_id:

{"question":"Which boundary?","domain":"fixture","severity":"medium","required_authority":null,"required_confidence":"derived","required_environment":null,"recommended_probes":[],"relationships":[]}

Import that same complete bundle into two fresh MCP sessions.
In the first session call update_unknown with this complete request, replacing UNKNOWN_ID:

{"unknown_id":"UNKNOWN_ID","expected_revision":1,"status":"open","severity":"high","supporting_evidence_ids":[],"contradicting_evidence_ids":[],"required_authority":null,"required_confidence":"derived","required_environment":null,"recommended_probes":[],"relationships":[],"resolution":null}

In the other session use the identical request except severity: "low".
Export both bundles and compare the records whose operation is update_unknown.

Expected behavior

Mutation Evidence should preserve the complete caller-selected update intent. Different requested state should be distinguishable in authenticated Evidence; the revision's backlink should identify the specific mutation it describes. Keep the optimistic-revision guard and existing imported Evidence valid.

Impact and scope

The actual Unknown snapshots retain the requested severity and have distinct authenticated revision digests. The loss is in mutation Evidence/provenance: its claimed analyst intent cannot explain which state was requested. This reproduces without a binary or native provider, and affects the shared registry used by MCP and application workflows. This is not a cryptographic SHA-256 collision: the Evidence's retained semantic content is identical because relevant request fields were omitted.

REA version

6.4.0 source build; commit 966dc3acde2880a0f94b2658e2a02180d505cafa

Runtime and platform

Node.js 24.18.0; Linux x64; real stdio MCP via installed @modelcontextprotocol/client 2.3.1. One CPU, explicit 512 MiB Node heaps and disposable client environment.

Target and artifact context

Registry-only Evidence bundle with one revision-1 Unknown, forked into two fresh sessions; no target binary.

Interface

MCP

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

high update -> severity=high, revision_digest=b9f8f00f72f729911c8b4ab0fa86bef7830e12d3ec92474c2710dc12d4869e2e
low update  -> severity=low,  revision_digest=ed28be4a03313030d99a9d7bb2b1bb41921d58e6eea42a0fb63d4732e102cd6e

Both mutation Evidence IDs:
ev_971651ab574a3ddabfa48c8e7f199bc2a0e73f386e4cf09209d764627e144321

Both parameters:
{"expected_revision":1,"unknown_id":"unk_17c170eb7deb9e42c851ef83919238cc712e1c8df9a0003a5cd68fb66bdd2003"}
Both normalized_result:
{"action":"update","status":"open"}

All three real MCP sessions discovered 170 tools; calls, exports, ping and awaited owned-process cleanup completed.

Typed outcome or recovery expected

Successful updates continue returning their retained Unknown; exported mutation Evidence includes the selected severity, authority/confidence/environment, probes, relationships, evidence categories and resolution as part of the caller's request. This should not require truncating input or rejecting previously valid persisted bundles.

Analysis or suspected cause

Source-derived cause: InvestigationRecords.updateUnknown projects parameters to only unknown_id and expected_revision, and result to action/status. unknownEvidenceLinks retains referenced IDs but cannot reconstruct the omitted fields or their categories. The creation producer also retains a partial request; that is related source-derived debt, while the reproduction above establishes the update defect specifically. Consolidate mutation Evidence production at its existing owner and retain the full typed command.

Additional context

The paired-session probe preserved complete exported bundles and verified distinct requested states, identical mutation Evidence and continued transport usability. No live model, real native provider or Windows behavior is claimed. Open/closed searches for update_unknown, unknown provenance and mutation intent found no matching report.

Originally created by @N0zoM1z0 on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1724 ### 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 Evidence, artifacts, or reconstruction ### Observed behavior Two different successful `update_unknown` requests can create identical mutation Evidence. In a real stdio MCP reproduction, the same revision-1 Unknown was imported into two fresh sessions. One request changed severity to `high`, the other to `low`; both kept status `open`. The returned Unknown states and revision digests differed, but both exports contained the same `update_unknown` mutation Evidence ID, parameters and result. Its Evidence did not contain either requested severity. ### Reproduction 1. Start REA stdio MCP with the source version below and SDK client 2.3.1. 2. Call `record_unknown` with this input, then export its bundle and retain the returned `unknown_id`: ```json {"question":"Which boundary?","domain":"fixture","severity":"medium","required_authority":null,"required_confidence":"derived","required_environment":null,"recommended_probes":[],"relationships":[]} ``` 3. Import that same complete bundle into two fresh MCP sessions. 4. In the first session call `update_unknown` with this complete request, replacing `UNKNOWN_ID`: ```json {"unknown_id":"UNKNOWN_ID","expected_revision":1,"status":"open","severity":"high","supporting_evidence_ids":[],"contradicting_evidence_ids":[],"required_authority":null,"required_confidence":"derived","required_environment":null,"recommended_probes":[],"relationships":[],"resolution":null} ``` 5. In the other session use the identical request except `severity: "low"`. 6. Export both bundles and compare the records whose `operation` is `update_unknown`. ### Expected behavior Mutation Evidence should preserve the complete caller-selected update intent. Different requested state should be distinguishable in authenticated Evidence; the revision's backlink should identify the specific mutation it describes. Keep the optimistic-revision guard and existing imported Evidence valid. ### Impact and scope The actual Unknown snapshots retain the requested severity and have distinct authenticated revision digests. The loss is in mutation Evidence/provenance: its claimed analyst intent cannot explain which state was requested. This reproduces without a binary or native provider, and affects the shared registry used by MCP and application workflows. This is not a cryptographic SHA-256 collision: the Evidence's retained semantic content is identical because relevant request fields were omitted. ### REA version 6.4.0 source build; commit `966dc3acde2880a0f94b2658e2a02180d505cafa` ### Runtime and platform Node.js 24.18.0; Linux x64; real stdio MCP via installed `@modelcontextprotocol/client` 2.3.1. One CPU, explicit 512 MiB Node heaps and disposable client environment. ### Target and artifact context Registry-only Evidence bundle with one revision-1 Unknown, forked into two fresh sessions; no target binary. ### Interface MCP ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence ```text high update -> severity=high, revision_digest=b9f8f00f72f729911c8b4ab0fa86bef7830e12d3ec92474c2710dc12d4869e2e low update -> severity=low, revision_digest=ed28be4a03313030d99a9d7bb2b1bb41921d58e6eea42a0fb63d4732e102cd6e Both mutation Evidence IDs: ev_971651ab574a3ddabfa48c8e7f199bc2a0e73f386e4cf09209d764627e144321 Both parameters: {"expected_revision":1,"unknown_id":"unk_17c170eb7deb9e42c851ef83919238cc712e1c8df9a0003a5cd68fb66bdd2003"} Both normalized_result: {"action":"update","status":"open"} ``` All three real MCP sessions discovered 170 tools; calls, exports, ping and awaited owned-process cleanup completed. ### Typed outcome or recovery expected Successful updates continue returning their retained Unknown; exported mutation Evidence includes the selected severity, authority/confidence/environment, probes, relationships, evidence categories and resolution as part of the caller's request. This should not require truncating input or rejecting previously valid persisted bundles. ### Analysis or suspected cause Source-derived cause: `InvestigationRecords.updateUnknown` projects parameters to only `unknown_id` and `expected_revision`, and result to action/status. `unknownEvidenceLinks` retains referenced IDs but cannot reconstruct the omitted fields or their categories. The creation producer also retains a partial request; that is related source-derived debt, while the reproduction above establishes the update defect specifically. Consolidate mutation Evidence production at its existing owner and retain the full typed command. ### Additional context The paired-session probe preserved complete exported bundles and verified distinct requested states, identical mutation Evidence and continued transport usability. No live model, real native provider or Windows behavior is claimed. Open/closed searches for `update_unknown`, unknown provenance and mutation intent found no matching report.

bsakaguchi

2026-10-15 18:26:22 +00:00