[GH-ISSUE #7694] [Bug] MCP validation catalog entry puts verification evidence in the status column #4616

New issue

Closed

opened 2026-10-31 00:51:23 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:51:23 +00:00

Owner

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

Before submitting

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

Area

Documentation

Observed behavior

Reading the error catalog with Python's standard header-based CSV reader assigns the MCP tool-input validation entry's verification sentence to implementation_status and returns None for verification_result. The eight-column header and that entry's seven fields do not align.

This is an executed read of the committed documentation artifact. No REA CLI or MCP failure was reproduced.

Reproduction

From the source checkout at the revision below, run:

python3 -I - <<'CHECK'
import csv
with open('docs/user-visible-errors.csv', newline='') as stream:
    reader = csv.reader(stream, strict=True)
    header = next(reader)
    print('header fields:', len(header))
    for number, row in enumerate(reader, 2):
        if len(row) != len(header):
            print('record:', number, 'physical end line:', reader.line_num, 'fields:', len(row))
            print('location:', row[1])
            print('implementation_status:', row[6])
with open('docs/user-visible-errors.csv', newline='') as stream:
    row = next(row for row in csv.DictReader(stream, strict=True)
               if row['location'] == '@modelcontextprotocol/server:tool input validation')
    print('verification_result:', repr(row['verification_result']))
CHECK

Observe:

header fields: 8
record: 103 physical end line: 117 fields: 7
location: @modelcontextprotocol/server:tool input validation
implementation_status: verified by real in-memory and stdio MCP client/server calls with wrong argument types
verification_result: None

The independent detailed parse and this compact reproduction both produced the same mismatch. No fixture files are required.

Expected behavior

The catalog should preserve the distinct implementation-status and verification-result columns named by its header. The MCP input-validation entry's verification sentence should appear under verification_result, with its implementation state recorded separately. The precise status to use should reflect the implementation evidence.

The existing header establishes the column contract; this does not assume a closed set of status tokens.

Impact and scope

P3 documentation defect. A reader using the header receives misplaced verification evidence and a missing verification result for this one entry. Of 107 data records, 106 have eight fields and this one has seven.

The repository's existing catalog test reads raw text and passes despite the mismatch. No runtime behavior change, failed import by another application, or data loss was established. External consumers and readership frequency are NOT_ENOUGH_INFO. A reader can recover the verification sentence by inspecting the line directly.

REA version

Exact node scripts/rea.mjs --version output: 6.8.0.
Source commit: 65f1c447344a423fa2785847dbcea1e9a9e2454a.

Runtime and platform

Node.js v24.22.1; macOS 27.0.1, arm64. Python 3 standard-library CSV readers inspected the committed documentation. No analysis provider or target artifact was used.

Interface

Other

Earliest failure stage

Unknown

Relevant output or evidence

docs/user-visible-errors.csv:1 declares eight columns, ending in implementation_status,verification_result.
The strict-reader output above identifies logical record 103 ending at physical line 117 as the only seven-field record. csv.DictReader maps its final sentence to implementation_status and supplies None for the absent verification field. Strict CSV syntax parsing accepts the file; equal-width inspection exposes the schema mismatch.
sed -n '117p' docs/user-visible-errors.csv confirms the affected record occupies one physical line. git blame -L 117,117 -- docs/user-visible-errors.csv attributes that line to commit e50a271c7.
src/main/messages.test.ts:15-27 reads the catalog as text and checks four recovery-message substrings. npm run test:local -- src/main/messages.test.ts passed: one file, one test. Searches of tests/ and scripts/ found no user-visible-errors reference, and the broader repository search located no column-count validation.

Analysis or suspected cause

Source-derived: the affected record contains a verification sentence as its final, seventh cell, leaving no separate cell for verification after implementation status. Adding the appropriate separate status field would restore alignment. The editing circumstances are unknown.

Additional context

Read open and closed catalog issues #7666, #7664, #5473 and its additional-row comments, #5077 and its closure comments, #5742, #5743, and #5078. Those concern other catalog entries. Open PR #7163 updates source-owner locations and leaves the affected MCP entry unchanged; related PRs #5278, #5519, and #6180 concern other rows. No matching short-record report appeared in completed issue, comment, and PR searches. GitHub rate-limited several later narrow searches, so duplicate absence is limited to the completed searches and inspected results.

Triage assessment

Impact level: P3
Assessment status: supported
Impact basis: The committed documentation misassigns one verification sentence to the implementation-status column. Its text-only repository test passes, and no consequential runtime behavior change was demonstrated.
Workaround status: available
Workaround basis: Reading the affected physical line exposes the verification sentence directly without modifying the catalog or invoking a provider.

Originally created by @coygeek on GitHub (Oct 28, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7694 ### 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 Documentation ### Observed behavior Reading the error catalog with Python's standard header-based CSV reader assigns the MCP tool-input validation entry's verification sentence to `implementation_status` and returns `None` for `verification_result`. The eight-column header and that entry's seven fields do not align. This is an executed read of the committed documentation artifact. No REA CLI or MCP failure was reproduced. ### Reproduction 1. From the source checkout at the revision below, run: ```sh python3 -I - <<'CHECK' import csv with open('docs/user-visible-errors.csv', newline='') as stream: reader = csv.reader(stream, strict=True) header = next(reader) print('header fields:', len(header)) for number, row in enumerate(reader, 2): if len(row) != len(header): print('record:', number, 'physical end line:', reader.line_num, 'fields:', len(row)) print('location:', row[1]) print('implementation_status:', row[6]) with open('docs/user-visible-errors.csv', newline='') as stream: row = next(row for row in csv.DictReader(stream, strict=True) if row['location'] == '@modelcontextprotocol/server:tool input validation') print('verification_result:', repr(row['verification_result'])) CHECK ``` 2. Observe: ```text header fields: 8 record: 103 physical end line: 117 fields: 7 location: @modelcontextprotocol/server:tool input validation implementation_status: verified by real in-memory and stdio MCP client/server calls with wrong argument types verification_result: None ``` The independent detailed parse and this compact reproduction both produced the same mismatch. No fixture files are required. ### Expected behavior The catalog should preserve the distinct implementation-status and verification-result columns named by its header. The MCP input-validation entry's verification sentence should appear under `verification_result`, with its implementation state recorded separately. The precise status to use should reflect the implementation evidence. The existing header establishes the column contract; this does not assume a closed set of status tokens. ### Impact and scope P3 documentation defect. A reader using the header receives misplaced verification evidence and a missing verification result for this one entry. Of 107 data records, 106 have eight fields and this one has seven. The repository's existing catalog test reads raw text and passes despite the mismatch. No runtime behavior change, failed import by another application, or data loss was established. External consumers and readership frequency are NOT_ENOUGH_INFO. A reader can recover the verification sentence by inspecting the line directly. ### REA version Exact `node scripts/rea.mjs --version` output: `6.8.0`. Source commit: `65f1c447344a423fa2785847dbcea1e9a9e2454a`. ### Runtime and platform Node.js v24.22.1; macOS 27.0.1, arm64. Python 3 standard-library CSV readers inspected the committed documentation. No analysis provider or target artifact was used. ### Interface Other ### Earliest failure stage Unknown ### Relevant output or evidence - `docs/user-visible-errors.csv:1` declares eight columns, ending in `implementation_status,verification_result`. - The strict-reader output above identifies logical record 103 ending at physical line 117 as the only seven-field record. `csv.DictReader` maps its final sentence to `implementation_status` and supplies `None` for the absent verification field. Strict CSV syntax parsing accepts the file; equal-width inspection exposes the schema mismatch. - `sed -n '117p' docs/user-visible-errors.csv` confirms the affected record occupies one physical line. `git blame -L 117,117 -- docs/user-visible-errors.csv` attributes that line to commit `e50a271c7`. - `src/main/messages.test.ts:15-27` reads the catalog as text and checks four recovery-message substrings. `npm run test:local -- src/main/messages.test.ts` passed: one file, one test. Searches of `tests/` and `scripts/` found no `user-visible-errors` reference, and the broader repository search located no column-count validation. ### Analysis or suspected cause Source-derived: the affected record contains a verification sentence as its final, seventh cell, leaving no separate cell for verification after implementation status. Adding the appropriate separate status field would restore alignment. The editing circumstances are unknown. ### Additional context Read open and closed catalog issues #7666, #7664, #5473 and its additional-row comments, #5077 and its closure comments, #5742, #5743, and #5078. Those concern other catalog entries. Open PR #7163 updates source-owner locations and leaves the affected MCP entry unchanged; related PRs #5278, #5519, and #6180 concern other rows. No matching short-record report appeared in completed issue, comment, and PR searches. GitHub rate-limited several later narrow searches, so duplicate absence is limited to the completed searches and inspected results. ## Triage assessment - Impact level: P3 - Assessment status: supported - Impact basis: The committed documentation misassigns one verification sentence to the implementation-status column. Its text-only repository test passes, and no consequential runtime behavior change was demonstrated. - Workaround status: available - Workaround basis: Reading the affected physical line exposes the verification sentence directly without modifying the catalog or invoking a provider.

bsakaguchi closed this issue

2026-10-31 00:51:23 +00:00

bsakaguchi referenced this issue

2026-10-31 01:13:39 +00:00

[PR #4616] [CLOSED] fix(mcp): leave shared observation providers to the transport that loads them #6334