[GH-ISSUE #719] [Bug] Process comparison returns revision_conflict for a valid retained capture pair #318

New issue

Closed

opened 2026-10-15 18:23:49 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:23:49 +00:00

Owner

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

Before submitting

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

Area

Evidence, artifacts, or reconstruction

Observed behavior

In one persistent MCP connection, two process captures and their changed-output comparison succeeded. After capturing the first command again, comparing the original/repeated observations returned revision_conflict with reason already-exists. Retrying the same pair produced the same failure. Sending the exact same inline Evidence pair to a fresh connection succeeded.

Calls were serial, and the client did not modify retained records. Retrying the original changed-output pair and repeating JS analysis still worked; a later wider-time-bucket pair also worked. The failure is specific to the observed pair and retained state, not all repeated operations.

Reproduction

Start a real REA stdio MCP connection with the pinned SDK.
Call capture_process_scenario for command A below; retain its exact returned structuredContent.evidence.
Capture command B, differing only in the printed JSON fields (total/query instead of count).
Call compare_process_captures({left: A.evidence, right: B.evidence}); observe success.
Capture the exact command A again as A2.
Compare A/A2 in the original connection; the evaluated pair failed twice.
Compare that exact A/A2 inline Evidence pair in a fresh connection; observe success.

Command A:

{
  "executable": "node",
  "arguments": [
    "-e",
    "console.log(\"{\\\"matches\\\": [\\\"one\\\"], \\\"count\\\": 1}\")"
  ],
  "working_directory": "<WORKSPACE>",
  "timeout_ms": 10000
}

Generated captures contain real timing/manifest differences. Freshly generated pairs may differ from the retained reproducer; do not claim every same-command pair fails. Forward complete producer Evidence without rebuilding fields.

Expected behavior

A valid independently captured pair remains comparable in its originating connection. Exact repeats should remain idempotent. A genuine import conflict should identify the conflicting entity/constraint and an available recovery action.

Impact and scope

Blocks a routine same-session repeatability question and forces reconnection. Fresh-state success establishes that these inputs are admissible. No evidence corruption, process leak, or internal collision cause was established.

REA version

REA 4.0.1, source revision c3bc38bf6c74d2175a4680530dcadd6cab0e7791; evaluation date 2026-10-06.

Runtime and platform

Node.js 22.19.0; Linux x64 on WSL2 (Ubuntu 24.04); pinned MCP client SDK 2.3.1. Windows-native behavior was not tested in this evaluation.

Target and artifact context

Controlled short-lived Node commands; process capture provider version 3; identical caller-selected working directory and normalization settings.

Interface

MCP

Earliest failure stage

Unknown

Relevant output or evidence

{
  "error": {
    "code": "revision_conflict",
    "category": "execution_failure",
    "message": "Evidence state changed before the update completed. Refresh the current state and try again.",
    "retryable": true,
    "details": {"reason": "already-exists"}
  }
}

Original connection: failure twice. Fresh connection: same inputs succeeded in approximately 19 ms. The message did not identify a usable refresh operation.

Typed outcome or recovery expected

Return comparison Evidence, or expose the exact conflicting entity and an applicable recovery workflow instead of a generic refresh-state message.

Analysis or suspected cause

Retained-state dependency is observed. Entity identity, registration/import behavior, and transactional conflicts are hypotheses for investigation; no implementation root cause was established by this black-box run.

Additional context

Hands-on public CLI/MCP evaluation, findings F08. Baseline: REA 4.0.1, source revision c3bc38bf6c74d2175a4680530dcadd6cab0e7791; evaluation date 2026-10-06.

Related history: #50 defines ledger deduplication; #706 addresses process provider identity and is already included in this baseline. This report concerns a retained-state-dependent conflict after successful capture/comparison, not the previously fixed provider admission failure.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/719 ### Before submitting - [x] I searched the open and closed issues and relevant pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior In one persistent MCP connection, two process captures and their changed-output comparison succeeded. After capturing the first command again, comparing the original/repeated observations returned `revision_conflict` with reason `already-exists`. Retrying the same pair produced the same failure. Sending the **exact same inline Evidence pair** to a fresh connection succeeded. Calls were serial, and the client did not modify retained records. Retrying the original changed-output pair and repeating JS analysis still worked; a later wider-time-bucket pair also worked. The failure is specific to the observed pair and retained state, not all repeated operations. ### Reproduction 1. Start a real REA stdio MCP connection with the pinned SDK. 2. Call `capture_process_scenario` for command A below; retain its exact returned `structuredContent.evidence`. 3. Capture command B, differing only in the printed JSON fields (`total`/`query` instead of `count`). 4. Call `compare_process_captures({left: A.evidence, right: B.evidence})`; observe success. 5. Capture the exact command A again as A2. 6. Compare A/A2 in the original connection; the evaluated pair failed twice. 7. Compare that exact A/A2 inline Evidence pair in a fresh connection; observe success. Command A: ```json { "executable": "node", "arguments": [ "-e", "console.log(\"{\\\"matches\\\": [\\\"one\\\"], \\\"count\\\": 1}\")" ], "working_directory": "<WORKSPACE>", "timeout_ms": 10000 } ``` Generated captures contain real timing/manifest differences. Freshly generated pairs may differ from the retained reproducer; do not claim every same-command pair fails. Forward complete producer Evidence without rebuilding fields. ### Expected behavior A valid independently captured pair remains comparable in its originating connection. Exact repeats should remain idempotent. A genuine import conflict should identify the conflicting entity/constraint and an available recovery action. ### Impact and scope Blocks a routine same-session repeatability question and forces reconnection. Fresh-state success establishes that these inputs are admissible. No evidence corruption, process leak, or internal collision cause was established. ### REA version REA 4.0.1, source revision [c3bc38bf6c74d2175a4680530dcadd6cab0e7791](https://github.com/morluto/rea/commit/c3bc38bf6c74d2175a4680530dcadd6cab0e7791); evaluation date 2026-10-06. ### Runtime and platform Node.js 22.19.0; Linux x64 on WSL2 (Ubuntu 24.04); pinned MCP client SDK 2.3.1. Windows-native behavior was not tested in this evaluation. ### Target and artifact context Controlled short-lived Node commands; process capture provider version 3; identical caller-selected working directory and normalization settings. ### Interface MCP ### Earliest failure stage Unknown ### Relevant output or evidence ```json { "error": { "code": "revision_conflict", "category": "execution_failure", "message": "Evidence state changed before the update completed. Refresh the current state and try again.", "retryable": true, "details": {"reason": "already-exists"} } } ``` Original connection: failure twice. Fresh connection: same inputs succeeded in approximately 19 ms. The message did not identify a usable refresh operation. ### Typed outcome or recovery expected Return comparison Evidence, or expose the exact conflicting entity and an applicable recovery workflow instead of a generic refresh-state message. ### Analysis or suspected cause Retained-state dependency is observed. Entity identity, registration/import behavior, and transactional conflicts are hypotheses for investigation; no implementation root cause was established by this black-box run. ### Additional context Hands-on public CLI/MCP evaluation, findings F08. Baseline: REA 4.0.1, source revision [c3bc38bf6c74d2175a4680530dcadd6cab0e7791](https://github.com/morluto/rea/commit/c3bc38bf6c74d2175a4680530dcadd6cab0e7791); evaluation date 2026-10-06. Related history: [#50](https://github.com/morluto/rea/issues/50) defines ledger deduplication; [#706](https://github.com/morluto/rea/pull/706) addresses process provider identity and is already included in this baseline. This report concerns a retained-state-dependent conflict after successful capture/comparison, not the previously fixed provider admission failure.

bsakaguchi

2026-10-15 18:23:49 +00:00